Alternate boot monitor on SB70LC?
Alternate boot monitor on SB70LC?
Does the SB70LC have an alternate boot monitor? I can't find a TP1 jumper so I suspect not. I've got a pair of boards that I may have bricked - I'm not getting any serial output on either one. Is there any way of recovering a bricked SB70LC? Is there any way to even tell if it's bricked because of a corrupted flash or if it's a more general hardware failure?
Re: Alternate boot monitor on SB70LC?
Hello Grant,
The alternate boot monitor is a feature made possible by the architecture of the processor of the module. The 5441x products have that capability, but it is not possible with the older products. It might be that you somehow enabled quiet boot mode, so I would start by putting the module in a dev board, running MTTTY, doing a power cycle, and sending an A to see if you can enter the monitor. Try both ports that way.
As an aside, the upcoming ARM M7 module, MODM7AE70, has a recovery method as well. So should not be brickable. More information on the new module coming over the next two weeks. That will be a feature of all our new modules. Just wasn't possible with the previous processors.
The alternate boot monitor is a feature made possible by the architecture of the processor of the module. The 5441x products have that capability, but it is not possible with the older products. It might be that you somehow enabled quiet boot mode, so I would start by putting the module in a dev board, running MTTTY, doing a power cycle, and sending an A to see if you can enter the monitor. Try both ports that way.
As an aside, the upcoming ARM M7 module, MODM7AE70, has a recovery method as well. So should not be brickable. More information on the new module coming over the next two weeks. That will be a feature of all our new modules. Just wasn't possible with the previous processors.
Re: Alternate boot monitor on SB70LC?
Tom, thanks for the quick response. I'm not getting any serial output even after power cycling and sending an 'A' on both serial ports. Just to confirm, a bricked SB70LC is definitely not recoverable, right? Also, there's no way to tell for certain if my boards are bricked or if there is some other hardware failure?
Would the flash normally be corrupted by a call to UpdateConfigRecord() or UpdateConfigRecord_Num()? Are there any other mechanisms that could corrupt the flash?
For background, I had several boards running a pre-release version of our firmware and two boards apparently died within a span of 2 days. The other 4 boards have not shown any other problems in over a week of continuous operation. It's reasonable to see occasional hardware failures but it makes me extremely nervous to see two boards die in two days. We haven't seen any boards just die like that in the past. I would like to rule out a firmware bug but at this point I'm afraid that we might never be 100% certain of what happened to those two boards.
Thanks,
Grant
Would the flash normally be corrupted by a call to UpdateConfigRecord() or UpdateConfigRecord_Num()? Are there any other mechanisms that could corrupt the flash?
For background, I had several boards running a pre-release version of our firmware and two boards apparently died within a span of 2 days. The other 4 boards have not shown any other problems in over a week of continuous operation. It's reasonable to see occasional hardware failures but it makes me extremely nervous to see two boards die in two days. We haven't seen any boards just die like that in the past. I would like to rule out a firmware bug but at this point I'm afraid that we might never be 100% certain of what happened to those two boards.
Thanks,
Grant
Re: Alternate boot monitor on SB70LC?
Grant,
I exclusively use the SB70LC in a product and haven't had a hardware failure in the entire 7 years. That said, twice it seemed that I bricked a SB70LC (my flash-based fault in at least one of them, if I recall) and couldn't recover it with the standard Setup Menu "A" (a procedure I'm all too familiar with). When I shipped each back to NB, they "fixed" them for me.(?) Were they replaced under warranty and I just didn't notice? I don't remember the details, but I thought they put each back in working order.
I exclusively use the SB70LC in a product and haven't had a hardware failure in the entire 7 years. That said, twice it seemed that I bricked a SB70LC (my flash-based fault in at least one of them, if I recall) and couldn't recover it with the standard Setup Menu "A" (a procedure I'm all too familiar with). When I shipped each back to NB, they "fixed" them for me.(?) Were they replaced under warranty and I just didn't notice? I don't remember the details, but I thought they put each back in working order.
Re: Alternate boot monitor on SB70LC?
Kackle123, thank you for the input. From a h/w failure standpoint, we have customers mention that units are still working great with over 17 years of service.
Grant, a h/w failure is unlikely, except for applications in which there are lightning strikes or some other type of surge voltage. As for flash corruption, there are two conditions I have seen over the years:
1. The application writes to the User Param or System Config flash sectors right after power-up. It is not uncommon for an end user to power cycle a unit on/off quickly once or twice. I can't explain why, but it happens. When you do a write to either of those areas the entire flash is accessible. If power is going down once the flash is enabled for writes, anything can happen. If random events are unlucky enough, the monitor gets overwritten. This has happened often enough that (as I mentioned) the 5441x and M7 products have separate flash memories that are write protected at the factory.
2. Writing more than 8k of data to UserParams, or attempting to write UserParams and have a bug in which you write to areas you do not think you are writing to. Could be a pointer or math error in size.
Unless you have a lighting strike, are operating relays without flyback protection, or have a ground fault, my first guess would be one of the two firmware issues above. Hope this is of some help in your troubleshooting.
Grant, a h/w failure is unlikely, except for applications in which there are lightning strikes or some other type of surge voltage. As for flash corruption, there are two conditions I have seen over the years:
1. The application writes to the User Param or System Config flash sectors right after power-up. It is not uncommon for an end user to power cycle a unit on/off quickly once or twice. I can't explain why, but it happens. When you do a write to either of those areas the entire flash is accessible. If power is going down once the flash is enabled for writes, anything can happen. If random events are unlucky enough, the monitor gets overwritten. This has happened often enough that (as I mentioned) the 5441x and M7 products have separate flash memories that are write protected at the factory.
2. Writing more than 8k of data to UserParams, or attempting to write UserParams and have a bug in which you write to areas you do not think you are writing to. Could be a pointer or math error in size.
Unless you have a lighting strike, are operating relays without flyback protection, or have a ground fault, my first guess would be one of the two firmware issues above. Hope this is of some help in your troubleshooting.
Re: Alternate boot monitor on SB70LC?
OK, thanks for the insights. I guess there's not much I can do to post-mortem the issue. I can't see anywhere in my code where I might be corrupting the flash so at this point I'm just going to keep an eye on it to see if it happens again.
Thanks again,
Grant
Thanks again,
Grant
Re: Alternate boot monitor on SB70LC?
The number one way this happens is for power to go away during a flash write.\
Some people write a boot count or other data to the userparam or STF file system space as soon as they boot.
The problem is if some one plugs the unit in messes with cords etc.....
It might boot for a second or two then have power fail then boot again....
(Note I can also induce the same effect with spastic reset button operation, flash left in programming mode while devicce boots )
We've had several customers with multiple bricked units that stopped having this problem by enforcing a no flash writes for 20 seconds after boot prohibition. Its fine to run any other code, but just delay writing to flash for 10 to 20 seconds.
Some people write a boot count or other data to the userparam or STF file system space as soon as they boot.
The problem is if some one plugs the unit in messes with cords etc.....
It might boot for a second or two then have power fail then boot again....
(Note I can also induce the same effect with spastic reset button operation, flash left in programming mode while devicce boots )
We've had several customers with multiple bricked units that stopped having this problem by enforcing a no flash writes for 20 seconds after boot prohibition. Its fine to run any other code, but just delay writing to flash for 10 to 20 seconds.