CC2640R2F: OAD function fails

Hello,

Were you able to previously evaluate OAD off-chip performance with LaunchPads?  Have you modified both the CC2640R2_LAUNCHXL.h linked file from the simple peripheral application project as well as the local bsp.h file on the BIM project?  Have you also changed the conflicting LED and I2C pins?  It appears as though the simple peripheral completes the OAD so the issue may occur during the reset and BIM startup procedure.  Please consider further debugging both application to gather further information as to what the direct issue is.

Regards,
Ryan

Yes, I confirm that the OAD function of my previous version of the hardware is normal without modifying the PIN port of the SPI bus. I have noticed the CC2640R2_LAUNCHXL.h and bsp.h files and the modification is complete.
Upon your reminder, I will pay attention to the I2C pin, and wait for my test and feedback tomorrow. Thank you very much for your help.

I tested it today and modified all conflicting pin ports, such as I2C, I2S, and changed them to PIN_UNASSIGNED, but the test results did not seem to have changed.

And what of debugging the simple peripheral application after the OAD update was complete along with the BIM application after the restart?  What are your SDK and CCS versions?  Are you able to compare the SPI communication from your previous hardware to your newer version to observe any differences?

Also, has your off-chip external flash memory device been pre-programmed with a valid BLE image?  Can you try following the BLE Enhanced OAD SimpleLink Academy Lab?  Do you experience any issues when attempting to use the nvsexternal example?

Regards,
Ryan

Hello,

In addition to Ryan's suggestions, please also review our SDK User's Guide section on Custom Hardware to verify you've made the correct changes.

After this has been verified, can you elaborate on the issue? What are you using as your OAD distributor? Upon reset, which version of device firmware is being executed if the OAD has failed?

HI Ryan, thank you for your reply. We have made three versions of this hardware, and the first two versions work normally. I posted the hardware schematic diagram for comparison, and identified the PIN port related to some changes in the OAD. On the previous version V1.01, the OAD function can work normally. My test method is to update the firmware and press the name of the Bluetooth broadcast Expected to change. But on the current version V1.02, it does not work normally after many attempts.
By the way, my SDK version is 5.10.00.02, and the CCS version is 10.4.0.00006.

HI, Ammar. I understand what you mean, but this hardware works normally on the previous version. The current version only modifies certain PIN ports. I haven’t been able to perform simulation tests on this place in a short period of time. This one is not very familiar, I will try to debug according to Ryan's suggestion when I have time.
The result of OAD failure is that the Bluetooth broadcast name is not updated as expected.

I noticed that v1.01 has slight variations to the LaunchPad, for instance SPI_MISO & SPI_SCLK have been swapped and FLASH_CS is on a different pin altogether.  You would have encountered an issue sooner had you not known where in the projects to change the code configurations.  Nevertheless, can you please confirm that CC2640R2_LAUNCHXL.h have been modified from source\ti\boards\CC2640R2_LAUNCHXL so that IOID_30 is no longer identified as CC2640R2_LAUNCHXL_DIO30_ANALOG?  This is the only other significant pin change that I recognize and will require that CC2640R2_LAUNHCXL.c is changed to reflect the missing analog pin.  Do you have multiple V1.02 boards that can be tested?  This would be to confirm that it is not a single hardware issue.

Regards,
Ryan

HI, Ryan

Yes, I noticed the exchange of SPI_MISO and SPI_SCLK when compiling the V1.01 version of the firmware. I made corrections in the firmware to make it work properly.
In my project, I have changed the names of CC2640R2_LAUNCHXL.h and CC2640R2_LAUNCHXL.c to Myboard.h and Myboard.c files for corresponding editing, and the file path inclusion has also been modified. In this way, my firmware can work normally (after the oad firmware is updated, the Bluetooth broadcast name has changed).
On the V1.02 version of the hardware, I tried a lot of boards, the number was not less than five, and the performance results of each of them were consistent.
Today I did some related shielding work on IDIO_30 and other PIN ports not used as analog IO, but the test results did not make any progress.
I don't know how to proceed right now. But thank you for your suggestions.

The OAD application would have returned an error if it were failing to write to the external flash memory device.  Further debugging of the BIM application and logic analyzer/oscilloscope comparisons between the working and non-working versions are most likely needed.  You could try to cut the SPI traces on one of your boards and sky-wire them to further determine if any board design errors are present.

Regards,
Ryan 

Now I can test OAD successfully every time, and the returned result is also successful. But it is always found to be a failure after the reset is started. I tried the APP and BTOOL tool on the mobile phone, and all the conclusions are consistent. Moreover, the read and write operations of my user program to the external FLASH work normally, and only fail in OAD, which I cannot understand.
So, next, I will use a very simple board to continue testing with LAUNCHPAD.
Thank you again for your guidance and help.

The BIM for off-chip OAD application is run after device reset to determine whether a valid image exists in internal flash and if the external flash has an image which has been marked as needing to be copied. This is why I keep encouraging you to debug the BIM inside your system.

Regards,
Ryan