Home AMX User Forum AMX Technical Discussion

MVP-8400 will not boot sticks on splash

I am working at home and my panel has locked up. The file has been working for weeks and when I tried to use it tonight it lokck up during boot on the splas screen and the green dot at the bottom blinks for a while and hen locks up as well. I tried booting with the bottom left and down ... no help I tried touching the screen during boot to get to calibration or setup... no help. Any suggestions???
Thanks

Comments

  • John NagyJohn Nagy Posts: 1,740
    Very typical behavior. Your flash card must be replaced. They wear out - arguably from a program design that writes the configuration to it in the same place, endlessly. Often you see the panel fail to load the touch point configuration at reboot for a while. You have to re-calibrate after each boot. Then usually the thing fails to accept a firmware update (due to trying to write in the worn-out spot, maybe?) and you can't finish a boot anymore. Or it just goes right from working to this. You need to replace the flash card.
  • AuserAuser Posts: 506
    There are several techniques for extending the life of the media:
    - A checksum or error-correcting code can be kept for block or sector in order to detect errors or correct errors.
    - A pool of reserve space can also be kept. When a block or sector does fail, future reads and writes to it can be redirected to a replacement in that pool.
    - Blocks or sectors on the media can be tracked in a least recently used queue of some sort. The data structures for the queue itself must either be stored off-device or in such a way that the space it uses is itself wear-leveled or, in the case of flash memory, in a block with a specially extended life.

    [...]On most contemporary flash memory devices, such as CompactFlash and Secure Digital cards, these techniques are implemented in hardware by a built-in microcontroller[citation needed]. On such devices, wear leveling is transparent and most conventional file systems can be used as-is on them.

    As far as I'm aware transferring projects is unlikely to cause this issue. We mainly see these sorts of failures in older panels that have been in the field for a long time. I don't know of too many people who would send projects to a test panel 100000 times or more.

    With limited knowledge of how the OS has been built, what write masking has been implemented and whether a RAM disk is in use, the cause is more likely to be temporary files written to the flash card at run time or simply fatigue due to age.

    Sandisk has an interesting and succinct white paper on wear levelling that you can find via a google search (the link on the Sandisk website is currently down).
  • Thanks for the recommendations

    I was hoping for a silver bullet. I will get a new flash card. Then I have to remember how I rebuilt one on about 8 years ago ;)
  • AuserAuser Posts: 506
    Be careful not to break the clips around the inside of the case - they can be tricky to pry open.
  • STILL WILL NOT BOOT any mor suggestions???

    I got a new flash card and it still will not boot. I picked up another older 8400 (that works) and tried its card in the dead panel. It would not boot. The old card works in both. The card from the problemed panel will not work in either. The differences in the 2 AMX supplied cards is the older panels (that will boot) is 64M v2.55.43 The panel that will not boot is 256M v2.89.3 and the new card is 1G. Any other suggestions??

    Thanks

    Mike
  • DHawthorneDHawthorne Posts: 4,584
    I got a new flash card and it still will not boot. I picked up another older 8400 (that works) and tried its card in the dead panel. It would not boot. The old card works in both. The card from the problemed panel will not work in either. The differences in the 2 AMX supplied cards is the older panels (that will boot) is 64M v2.55.43 The panel that will not boot is 256M v2.89.3 and the new card is 1G. Any other suggestions??

    Thanks

    Mike

    There are portions of the bootstrap that are in NVRAM and portions that are on the CF. They have to match, if not exactly, at least enough to be compatible. But it's also possible the NVRAM got corrupted, in which case there is no choice but to send it to AMX. And though Auser is correct that a transfer isn't likely to be the cause of your failure, it can certainly be a trigger. It's generally on a reboot cycle that the memory fails, and a transfer forces a reboot.
Sign In or Register to comment.