We are using a MAX 10 (10M04SCU169A7G) on a custom board and are experiencing start-up problems on 2 out of 40 boards. The MAX 10 is programmed by an MCU on the same board using the embedded version of Jam STAPL Byte-Code Player. The jbc-file is embedded into the MCU firmware. All communication over JTAG between the MCU and MAX 10 always succeed. We have tried to program, verify, erase and blank check and all results are as expected.
In Quartus Prime 20.1.0, configuration mode is set to Single Uncompressed Image (128Kbits UFM). All other settings are default set by Quartus. Real-time ISP is not used. Auto-restart configuration after error is activated.
tRAMP during POR is ~1.25 ms which is ok according to the Configuration User Guide.
CONFIG_SEL, nSTATUS, nCONFIG and CONF_DONE are all pulled up to 3.3V using one 10Kohm resistor each.
We have observed nCONFIG, nSTATUS and CONF_DONE on an oscilloscope during start-up and after reprogramming of the MAX 10 and have noticed differences between a working board and one that does not. As expected the configuration pins on the working board follow the configuration sequence in the Configuration User Guide.
Attached picture (startup-not-ok.PNG) shows the pins during start-up on a board that does not work. The MAX 10 is already programmed and nSTATUS go high for a short while (~0.8us) before going back low. CONF_DONE is low all the time.
Attached picture (startup-ok.PNG) is the corresponding picture for a working board. Here we can see nSTATUS go high followed by CONF_DONE a while later as expected.
Attached picture (after-programming-not-ok.PNG) shows the pins after reprogramming a board that does not work. Here nSTATUS and CONF_DONE go high while programming the MAX 10. When programming is completed both go low and then nSTATUS go high for a short while (~0.8us) before it goes low again. CONF_DONE remains low. Same behavior as during start-up.
Attached picture (after-programming-ok.PNG) is the corresponding picture for a working board. Both nSTATUS and CONF_DONE go low once reprogramming is completed. Then nSTATUS go high followed by CONF_DONE just like during start-up on a working board.
Judging by the behavior of nSTATUS something seems to go wrong during configuration. We have used the Jam STAPL player to verify the data written to FLASH and the check succeeds. Do you have any idea what could go wrong? 95% of the boards work. The same JBC-file is programmed to all boards. Since we have activated Auto-restart configuration after error we expect nSTATUS to go high again after a timeout but we cannot see that.
We have managed to get one of the problematic boards to start-up correctly by doing a fullchip erase and program the MAX 10 again. This might fix the other board as well but in order to do more troubleshooting we have elected not to try it yet.
In our prototype series of 10 boards 3 of them experienced this phenomenon of which 2 ”self-healed” by reprogramming the MAX 10 enough times. On one board the problem still remains. We assumed the cause of the problem was that we did not connect nCONFIG to a 10Kohm pull-up resistor but that is fixed now on the current boards. We cannot say with certainty that we have the same problem now but the symptoms are the same.
Translation for legend in attached pictures:
Grön = Green
Blå = Blue
Gul = Yellow
Röd = Red
Spik = Spike
Since 2/40 boards are having issue and all of them are having the similar setup. Chances that the issue is due to device or the trace/termination on the board.
Can you do swapping on the faulty board with known good device? Also, if the recommended pin connection guidelines on the MAX10 is not fulfilling, it could cause trouble also in programming/configuration.