Within the Tag board environment (working on your side), your application will be automatically loaded to EEPROM initially, and then to internal RAM (30KB available) on boot up for execution.
In this scenario, during programming the SDK essentially downloads a minidriver to RAM and then runs it, it then pushes the application code over the HCI uart (via the FTDI to serial device on the Tag board) to the minidriver which will then write the program to EEPROM.
It almost sounds like the program running on your custom board loads fine into RAM, but does not reside in NVM (512K of EEPROM on the module), so on reset, it needs to be regrammed each time. Let me check with the firmware team to see how this is possible.
Are you using the WICED SDK to program your board directly through a header, or are you programming the board via a 920732 Tag Board?
Thanks for your reply and for looking into the matter.
I am programming a custom board with the 20732S module on board directly through a header.
I spoke to the firmware team and they said that it's not possible to write an application directly to RAM and run it from RAM. They believe that there has to be something else going on here and suspect it may be related to power to the NVM? Or, you could have something hanging off the I2C bus that could be interfering with the config read during boot.
We do have a PCA9534(TI IO expander) wired to the I2C bus. Would this be the source of issue?
Another thing you will want to check is the state of the HCI UART Rx line during reset.
By default, there is a 10k pull down on Rx that's internal to the module which should keep the line from going into programming mode. However, if you are using somehting like an FTDI USB to Serial converter between your PC and the board, it's possible that the FTDI device could be pulling the Rx line of the HCI UART high and preventing the device from going into application mode.
When sampled on RESET only:
HCI UART Rx = High (Programming mode)
HCI UART Rx = Low (Application mode)