Home/Support/Support Forum/RCM4300 modules failing
Welcome to Digi Forum, where you can ask questions and receive answers from other members of the community.

RCM4300 modules failing

+1 vote
We are having problems with RCM4300 boards failing.... We don't know that exact cause, but the symptoms are that the board works fine for a couple of years - then we start getting problems with program settings becoming corrupted in RAM.... Also - if we try and re-program the same application - it times out in RFU when trying to Erase the flash. Then, Sometimes programming a different application on the board works - but after a while even that stops working.

We need to do more research into the issue - and try and find out exactly what has failed on the boards if we can, but just asking on here to see if anyone else has having similar problems. Its not 1 off problem.........

Any tips on how we might find out what has failed would be good too (ie a test program for testing the hardware on the board??)
asked Mar 29 in Rabbit by keef New to the Community (3 points)

Please log in or register to answer this question.

1 Answer

0 votes
Does your program write to the flash, perhaps with the writeUserBlock() API or APIs from SFLASH.LIB? Or have a file system on the portion of flash that isn't used for firmware? How frequently does it write?

I don't know the exact part number, but a similar flash is good for at least 100,000 writes/page: https://www.adestotech.com/wp-content/uploads/doc8784.pdf

You'd exceed that limit if you wrote every 10 minutes for two years. You may also want to read section 8.3 "Auto Page Rewrite" to see if it might apply. It states, "This command only needs to be used if the possibility exists that static (non-changing) data may be stored in a page or pages of a sector and the other pages of the same sector are erased and programmed a large number of times.
Applications that modify data in a random fashion within a sector may fall into this category." That may apply for the static System ID Block at the tail end of the flash, and changes made to User Block Data pages in the same sector.

You mention program settings becoming corrupted in RAM -- if you are using battery-backed RAM then you would need to replace the battery. But settings in RAM wouldn't explain the inability to install new firmware.

I do not know of a method to check the write count. It would be up to you to model that based on a review of your code.

If you have exceeded the write limits for a particular page of the flash, the only solution is to replace the serial flash memory and use Utilities/Write_ID/write_idblock_rcm43xx.c to create a System ID block on the new flash memory.

And, of course, update your firmware to limit writes to the flash by spreading them out over multiple pages, or just reducing the frequency to the absolute minimum necessary.
answered Mar 29 by TomCollins Veteran of the Digi Community (2,109 points)
...