MOD5270B Firmware ?
Posted: Wed May 06, 2009 1:26 pm
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
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