We have a carrier board that we solder the RCM3400 onto.
The boards are tested before soldering onto the board and then they are programmed once onboard.
Of the 16 units created, two will accept the new firmware, but do not run once firmware is uploaded. They will not run in debug mode from Dynamic C either.
Unfortunately, due to space constraints, the boards are soldered in and realistically, the only option for taking them off is to dremel the RCM boards in half to get access to the pins to properly desolder them.
We also replace the onboard oscillators with pressure tolerant variants from the carrier board.
I have checked that the clocks are received at the right pins and that they are the correct frequency.
I have checked power voltages and ground connections.
I have checked the voltage at SMOD1 (programming pin) though this shouldn’t affect debug mode.
I have checked the votage at RSTIN (reset).
I am at a loss on what to check next and would like to find a problem that is common to both boards, in case it is systematic.
This is a fairly complicated debugging scenario, and I recommend opening a case with Digi to get assistance with troubleshooting it. If Dynamic C and RFU can bootstrap the board and read its System ID Block (identifying the board type) and install firmware (write to flash) it should be close to working.
You could try running a simple sample from Dynamic C’s “compile to RAM” mode. Something that just flashes an LED at startup.
And I also recommend looking into ways to use sockets instead of soldering the core to your main board. I myself had a product using RCM2200-series modules and soldered them in the first revision of the product. It made troubleshooting difficult and expensive, plus soldering the core modules meant I could not get warranty service on any that were bad. It was difficult to fully test the main board without a core installed, and difficult to do board repairs after soldering the core.
I changed enclosures and had enough space for headers. I had looked at whether I could put SMT headers on the bottom of the board, and have the pins pass through holes or a cutout in the board and enter the back of the header.
Thank you for your time in such a comprehensive answer.
Believe me, I’ve pushed for a header and we do typically use them with the 2000 series devices. It’s just not an option and will create a major redesign.
Where do I find a sample file? It’s not something I can immediately find
Partial success. One of the boards would accept the Demo1 firmware and worked away. So I found the place in my code that caused the run to fail. Isolated the associated hardware and got the board to run. Easy fix.
The second board will not accept run the demo firmware and it doesn’t look like it’s the same issue as the first board.
When running in debug mode, the firmware is downloaded to the device, there is comms both ways on the programming line, but when the program should start,DC throws an error: “While Sensing User Program: Timeout while waiting for response from target.”
If I was troubleshooting this, I would use a logic probe to capture the serial port A traffic (used as the debug interface) and compare it between the working and failing hardware. It’s going to be difficult to identify whether the RCM4300 was damaged during manufacturing, or if there’s something in the baseboard hardware causing problems (e.g., pulling an I/O line low or high).
Of your 16 units, are the other 14 (plus the repaired board) working correctly? I think for the board that continues to fail, you will need to run various tests to compare it to boards that are working.