With the 13 bad board I can't recover or downlaod with the SDK solution. I can recover or download with all 55 other one.
You tested on 20737S, is this the same chip that is on your boards or is it a 20737?
You mention a 100k pull up. What pin is the pull up on?
Would you be able to either post your schematic or email it to firstname.lastname@example.org?
100k pull up are on the I2C.
From the 13 bad board, on one board, I remove the 2 resistors and the I2C chip I have on the line and I still can't program them.
I sent you the schematic via email.
Anything I could try ?
Based on your traces, it appears that code is loading into RAM, but never loading anything from NVRAM.
You've already ruled out an issue on the i2c bus. I would have also tried this first.
The quickest thing I would test is to cut the trace to RST_N and pull it high. Despite having a schmitt trigger, activity on p0 could still be dangerous to the download process.
Other than that, I would monitor all the voltage rails in the download process. One possibility is that an unstable voltage dips too low for the EEPROM chip and corrupts the download.
I can also take a look at your code if you'd like (send to same email), although I do believe this is a hardware issue.
Hi, Thanks for the suggestion.
So after Pulling Up the Reset, and disconnect the output of the trigger, nothing new. I can't program the chip.
There is a difference between the production and my workbench, production use 3.3V to program the board, I use the SmartTag and voltage is 1.8V
I did try to replace the 100k by 10k pull up in the I2C (instead of removing it) no difference.
I prob the I2C, SDA and SCL, no activity or what so ever.
Anything I could try ?
I'll send you my code over the email
You don't see any activity on i2c during boot? You should at least see the chip probing the EEPROM to check that it exists.
What's the voltage on the i2c lines? Are they completely disconnected from everything on the board? You shouldn't need pullups on them, the module has 10k pullups internally.
Can you monitor all the voltage buses during boot an ensure they're not dipping too low?
The SDK should be able to recover the board no matter what. To be clear about the recover process, you have held SDA low while rebooting the board, then in your make target added the 'recover UART=COMxx' directive?
If the board truly doesn't recover, the EEPROM could simply be fried. The chip sounds active with the traces you showed me, but it clearly isn't executing anything from NVRAM.