This post is a bit wired, I tried several stuff, but still nothing improving the situation.
I did developped a BCM20737S application, this application works well. We were moving this project to production, the first prod was 50.
From production I did get back 13 board where they can't do something with it. (hopefully we purchase 100 boards, so 50 are working 100%, 13 doesn't what I discribe below)
So we can :
- Download the code through the chipload and the script, this succed.
- When I do this, the chip lunch the app, stop printing something on the UART after 3-4 sec and then reboot.
- we have a bi color LED on GPIO 24 and 25, these output are high and the LEDs switch ON, which isn't normal as other board doesn't do this.
From this, I take the board, try to flash then though SDK.
- I can't Download neither recover.
- I try to download and recover all 13 board, nothing.
- From this I tried to flash with the script and this still succed.
I had once a problem with the boot sequence and I had to change the PMU crystal warm up tp 5000, this doesn't help in this situation.
I have a I2C chip to do DAC function, I tried to remove it, then I try to remove the pull up, still I can't download or recover.
I did test the recover on a board that works and I can do a recover.
I do have pull up 100k, this will be changed in the following BOM, but still if I remove them, I can't flash.
PS : I can send anything MP if needed, but I wont post code or something like this public.
Thanks for the reply !
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.
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.