Page 1 of 1

MOD5270B Firmware ?

Posted: Wed May 06, 2009 1:26 pm
by SteveD
Hi All

This post falls between Hardware and Software, so I'm not sure where it should go.

I have just recently received a batch of MOD5270B boards with New Monitor Revision
1.0, and on downloading any of my previously working applications found out that they just trap. (old boards were MOD5270 Mon V1.3).

The line of code that seems to be the culprit is the call to the system library function
that does Manual Ethernet Setup (in ethernet.cpp) which I am using to set the
ethernet link to 10Mb/s Full duplex. Currently I have just remarked it out, but I know
for a fact that there are some modules on site behind old 10Mb fiber converters which
do not support autodetect, so I know my s..t is in the post...

The link status function (in etherprint.cpp) also always returns that there is no link,
and this seems to be caused by the fact that it is testing MII reg 1 against 0x0024,
which is the auto-negotiation complete flag and the link status flag...
As mentioned before, I am not using auto negotiate in some cases, so you should
just test against 0x0004, otherwise it just always returns FALSE (This function was
broken recently, as I have an older version of the code that works...).

Apart from Immediately forcing me to upgrade my toolchain to the latest one, with its
accompanying other things (other apps suddenly breaking, etc..), I have experienced
that the monitor goes into a mode that continuously tells me that the S records in the file start at the wrong address, and refuses to flash the app until I do a power cycle, and
then lo and behold, the same file it was rejecting updates into flash and executes.

I realize that the new board has had a major rework, with new phy and ram chip,
but Guys, a two day debugging session on a previously working product that was ready to be shipped out of the door, (except fot the Netburner modules) shouldn't be necessary.

Regards Steve
:(

Re: MOD5270B Firmware ?

Posted: Wed May 06, 2009 2:42 pm
by BBAdmin
Hello Steve,

Sorry to hear this has been an issue. The old PHY was in end of life, so we had to change to a different one. In doing so, we upped the SDRAM to 8MB, selected a PHY that is available in industrial temperature range with auto-mdix, and added an option to use a 10-pin header in place of the Ethernet jack for those who wish to mount the RJ-45 on their carrier board. The industrial temperature version will be out in a few months. There will not be a price increase.

For the record, we regression tested and ran a large number of beta sites for reverse compatibility using the standard API function calls. All tests showed that existing applications worked properly. Your situation in which you access the PHY registers directly is not something we anticipated or tested against. You may be able to modify what you have per the new Micrel PHY register data sheet and have it work without an upgrade, but I am not sure. If you need further support on this we would be happy to help through support.netburner.com so you can communicate directly with the people who implemented the change. Again, sorry for the problem, but we had to change the PHY.