NP-41 Emulator (may be)
|
01-10-2018, 01:53 PM
Post: #356
|
|||
|
|||
RE: NP-41 Emulator (may be)
An update on the current NP-41 status
Dumping all the memory from Milton's faulty unit I compared it w/ the original firmware image. There are isolated spots (3 word size memory locations) got overwritten by a same word of 0xF81A. They are on the code area and depending on the runtime situation, it could cause a freeze or a reboot. I had since studied related datasheets and other technical documentation regarding this chip and still cannot understand how this could happen. I then accidentally "bricked" my test unit. I.e. for some reason it could not reach the emulation mode (i.e. cannot get to MEMORY LOST w/ the ON + <- sequence). And I dumped the memory and found that the same memory corruption w/ the same overwriting 0xF81A word. The thing I was doing was snapping the battery on and off, which I did quite a bit during testing. It is the intermittent power applying to the unit that is causing the memory corruption. I can now reliably brick the unit by holding the battery against the housing and rub around it (to apply power intermittently) and this will cause the memory corruption. I had tried to debug the code, had introduced memory locking (deny write permission on code areas), install interrupt triggers, etc. And still the problem exists. I finally tried removing the bootloader and the problem went away. So it was the introduction of the bootloader that had somehow caused this issue. Tracking back on the delivery, all the 10 units were sitting on my bench for 6+ months (built in April and May) and back then, they do not have the bootloader. My other 2 test units were used for active development, including the newish ROM loading and bootloader. When I decided to sell the units, I updated the firmware on all the 10 units (w/o removing battery) so they all have the bootloader. I continue to test them for a week or so without problem (again w/o removing battery). It is when it's time to ship that I remove all the battery and put them into the boxes. As postage does not allow shipping overseas lithium batteries. When customer's received the units, they would insert a fresh battery. And if as such the insert was not done in a swift way (w/ some jiggling into the housing), there is a high chance to cause memory corruption, which I can now reliably reproduce. I would suspect that many failed units failed this way. I am trying to understand why the bootloader is causing this problem. Looking at how the bootloader operates differently than a normal firmware. This bootloader is a custom made one, as the on-chip factory bootloader requires a lot of extra circuitry. I had used the many year old trick of replacing the reset interrupt pointer to point to my bootloader 1st, so that bootloader takes control when unit powers up, and bootloader will check if the USER key is on-hold, and release control / branch to original firmware only if the USER key is not pressed. The bootloader is small (<256 bytes) and designed to be that way. It resides very high in the memory (to avoid overwriting itself). It skipped a lot of general initialization like most peripheral initializaton, stack setup and other memory initialization. I will be looking into these areas / differences to find out how it causes the memory corruption. It is possible that this occurs when power was interrupted when the MCU is in the bootloader and not yet reach the general setup code segment. First batch units cautions In the meantime, first batch owners should use caution to replace the batteries. You need to do it swiftly when both removing and inserting a battery. Since there is no physical power switch, any jiggling when replace battery may cause the memory corruption. I think placing a plastic slip / tape underneath the cell when inserting and pull it out after inserted might help. When using serial interface, leave battery in-place, and not to connect the V+ power from the USB dongle. This will avoid power resets to the unit. Power resets does not cause problem, it's the jiggling of power that will cause problem. There is also a chance to brick the unit during a bootloader firmware update. It is caused by the fact the the reset interrupt vector is only replaced at the end of the firmware update. So during a firmware update (takes about 25 seconds) if the unit got interrupted, you will lost the bootloader. burning a wrong image will not, so if you found out during download you forgot to set binary mode, or you had selected a wrong image, leave it alone and finish the download. I will provide the next firmware w/ the bootloader vector in the beginning of the image so as to reduce the chance of this would be incident. I will provide update when additional progress is made. +Guenter, +Egan, The two 2nd batch units are running good and I have confident that they will behave well once the bootloader issue can be resolved. Still I will compare them with new PCBs when they come in. I will update you w/ our options when I get a solution to the memory corruption issue, which shouldn't take long. (or at least have a good work around on it). Also other owners, if your unit fails on you please don't hesitate and let me know. You have a 1 year warranty on them. cheers. |
|||
« Next Oldest | Next Newest »
|
User(s) browsing this thread: 1 Guest(s)