Can anyone shed light on the following: Net+50 boots ok from flash, runs code from SDRAM for a few minutes (variable), then crashes - no serial or Ethernet comms - with CS1 pulsing low twice at 1.2us intervals. BCLK is still running. All chips are marked “B/0136991”, and the SDRAM Reset problem is worked around using PortC0 as per Errata. Reset comes from a MICREL 8114 device. When interrogated via the JTAG/Debug port, target claims to be running and cannot be stopped.
Do you use DMA and any of your chip selects has 3-wait states? The NET+50 Revision 1 (0136991) has a bug in the MEM controller. It is not possible to use 3-wait states and the DMA controller. This leads to undefined crashes. All other wait state values seem to be OK.
Hi,- Are using BSP or a customer tailored board ? - Can you start the program from debug, step by step ? - Can you set the breakpoint into crash_for_debug function (romstart.c) to discover the crash reason ? - How many led blinks you have ? init.s has a (error x blink) table. The document that helped me a lot was “Initialization Enhanced with Block Diagrams.doc”, provided by NS. My main problems were (customer hardware): - Bootstrap configuration (16/32 bits) - Net50 behavior at booting - Wait states configuration - Clock configuration (PLL) - CSs configuration - Cache configuration - BCLK line. This signal is very critical. The layout must be fine. Almost all problems were misconfiguration problems. Marcelo (barros AT smar.com.br)
what date code do your chips have? We had a similar problem, target crashes and the only thing it was doing, was refreshing the sdram every 1.2us. But we only had this problem with the cache turned on. NetSilicon told us, that a few chips with the date code 0141 were buggy. They sent us chips with the date code 0149. We replaced the chip and since then we didn’t have this problem again.
Based on a small sample, we think that the Net+50-3 does not exhibit the same failure mode. Additional information is that a “crashed” Net+50-1 is actually in some zombie state - probing the Reset input to the Net+ARM can cause the system to resume (not reboot).
Thanks, Marcelo. This is a 3rd party module with uC/Linux not ThreadX. It runs fine on their eval board, but some (not all) of their modules crash on some (not all) of our carrier boards.
On this design, we use DMA but none of the CS are set to 3WS. Thanks for info - useful for future.
There is another problem when cache and burst are used togheter.
Cache is turned off. Maybe there’s a glitch on the Reset pin, so Net+50 goes into an invalid state?