Bootloader for BCM20736S (CYW20736) over SPI

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
RoWo_4704901
Level 3
Level 3
First like received First like given

Folks,

I am investigating whether it is possible to update the [user] firmware on the BCM20736S. On the product, the 20736 is connected to a microcontroller via the SPI port. The HCI UART is only accessible via an external header and you have to take the unit apart to get at it.

The micro connected to the 20736 is connected to the Internet and I can download firmware images from a remote server and pass it to the BLE module via SPI. So, my questions are these:

1. Is it at all possible to reprogram the BLE device over SPI?

2. If it *is*, do you need to create a custom bootlader?

3. If you do need to create a custom bootloader is there any documentation about how to do this? How difficult  would a bootloader be to implement?

4. If you do *not* need a bootloader to reprogram it over SPI:

     a. how do you put the 20736 into bootloader mode

     b. What are the exact commands that need to be passed to the unit?

5. If none of the above is possible, can you reprogram it over BLE? I appreciate this would be dog slow becasue it's only BLE 4.1 and therefore very small characteristics, butthis would be better than nothing.

This is of urgency to our project which is trying to keep medical staff safe during the Covid pandemic, so we would really appreciate a fast reply to this issue which we've been struggling with for quite some time. .

FWIW we are using the WICED framework for the custom software being run on the SoC.

I should possibly say that there is *no* external memory on the 20736.

0 Likes
1 Solution

Hi RoWo_4704901 ,

I am sorry for not giving a proper explanation. The problem is 20736 is a bit old chip and there is no single doc on programming spec for the CYW20732/36/37.

I will try maximum to get maximum inputs which help to clarify your queries.

1. For the factory programming , you need to use either our WICED SDK / Chipload.exe / a custom GUI app to download the initial hex of application code with UART / SPI / OTA FW upgrade option . This completely uses HCI UART. There is no other option to download the code for the first time. For this step refer to the blog here : Programming the TAG2/TAG3 Board using command line tools .

2. For the memory app architecture refer the blog here - BCM20732 Memory Map Architecture

3. When you include a FW upgrade option like UART/SPI/OTA - the EEPROM / flash memory is split such that there will be two sections . One for storing the current application and one for writing the new image. So that even if there is a power failure during upgrade process, the previous one will be retained.  As per my understanding all these options (SPI/UART/OTA FW upgrade) uses same memory divisions . Please refer to blog here - WICED Smart BCM92073X OTA Firmware Upgrade (1)  & WICED Smart BCM92073X OTA Firmware Upgrade (2)  You may need to concentrate on the sections - Section Change after Flash Download    , Section Change after OTA Firmware Upgrade  

4. If you need to retain the FW upgrade option even after first FW upgrade, then you have to make sure you have included the upgrade sections in the current application code as well.

5. Here the UART/SPI bootloader is as part of the application code. For example, if you refer to UART FW upgrade example in the SDK, the FW upgrade starts when the application receives a start command (WS_UPGRADE_COMMAND_START) .

As its an old chip and less documentation available, I am sorry , I would suggest you to go through the blogs which helps to clarify the details and then refer to the example application code available in WICED SMART SDK.

After going through the blogs, if its still won't clarify your doubts , please list it . I will try to explain it further.

Also I would recommend you to use OTA FW upgrade so that there will be less confusions for your development.

Thanks,

Anjana

View solution in original post

18 Replies
RoWo_4704901
Level 3
Level 3
First like received First like given

Bump.

There must be someone at Cypress who can take a few minutes to answer these questions.

0 Likes

Adding members of the Applications team with experience supporting Bluetooth controllers.

AnjanaM_61BoonT_56XinghaoZ_26WinstonF_61SheetalJ_96DheerajP_41DheerajK_81

AnjanaM_61
Moderator
Moderator
Moderator
5 comments on KBA First comment on KBA 5 questions asked

Hi RoWo_4704901 ,

Sorry for delayed response from our side.

There is no ready application  FW upgrade via SPI interface. But please refer to ws_upgrade.c available in WICED smart SDK-   /WICED-Smart-SDK/Apps/uart_firmware_upgrade/ws_upgrade.c

There is UART FW upgrade example available in WICED Smart SDK - /WICED-Smart-SDK/Apps/uart_firmware_upgrade . You may refer the implementation.  And the recent test results for the example done for a thread request available here - Re: FW Update without External Memory

Over the air upgrade option is also available. Please refer to ota_firmware_upgrade example , WICED-Secure-Over-the-Air-Firmware-Upgrade.pdf available in WICED Smart SDK .

Other references:

Memory Architecture - BCM20732 Memory Map Architecture

WICED Smart User's Guide

Regards,
Anjana

Hi and thanks for the reply, it's much appreciated.

I do feel this is not answering a number of my questions though. To repeat the ones I think are unanswered:

I am still completely unclear about whether this is going to need a custom bootloader.

Also, if you do need a customer bootloader how do you put the unit into bootloader mode in the first place. Is there documentation rather than just reading source files and trying to reverse engineer it?

Normally you'd have - in something like an STM32 - which is also a Cortex:

Area 1: Bottom Of Flash:

     Bootloader Code which never gets erased

Area 2: Bottom Of Flash + Size Of Bootloader Code:

   

     Normal Application

Bootloader Code would erase and reprogram Area 2 as it gets commands in from the outside world.

Is this what is going on here?

If not, I can imagine you could put a unit into bootloader mode that would run out of ROM and you could send commands over SPI that are specifically for self programming, I'm guessing that's what happens with the HCI UART. However, I am still totally in the dark as how you'd switch the 20736 to bootloader mode. I'm not at all convinced though that this is what's going on.

:

These patches you talk about in the linked article. What is a patch? Is it an indpendent piece of code that can run and erase other parts of flash? Or do all patches have to be reprogrammed at once (whatever a patch is).

0 Likes

I have further questions on this from reading a bit of rhe source code, which seems indecipherable without some documentation. There is this:

// WARNING: Invalidates the current SS. Should be called only when upgrade succeeded and the upgrade

// SS was also created successfully before by ws_upgrade_create_upgrade_ss.

// Failure to do this correctly will result in bricking the device.

void ws_upgrade_invalidate_active_ss(void)

Talking about bricking the unit gives me the heebie geebies. We cannot have any risk of bricking this in the field.

When the UART does this download where does it store the new image? Is it storing it into RAM and then transferring to EEPROM when the whole image is received? You seem to have EEPROM not flash).

Or is this little program running in a small bit of RAM and programming the EEPROM. I assume that everything gets copied out of EEPROM into RAM at boot? Surely if it's a bootloader there must be a little bit of EEPROM that is never erased ? I'm at a total loss as to the mechanism for copying one bit from EEPROM into RAM. Is there a small bootloader code that is always pulled into RAM and then dependent on  certain conditions it will then say "We don't need this bit of code, so we'll now load the main app into RAM"?

What if it gets partway through reprogramming and the power fails? Will it still use the bootloader at  boot next time even if it's partway though reprogramming the EEPROM?

So, to summarise this latest set of questions:

1. Does this ws_bootloader code always stay in EEPROM once it's programmed over HCI?

2. If so, how do you only copy that bit from EEPROM into RAM?

3. Can you have this ws_upgrade code copied from EEPROM to RAM at any point or can it only be done at boot? If so, how is that done? If the ws_upgrade code is run form the main app and if the upgrade fails halfway though, that will brick the unit, no?

If this is all part of one piece of software and part of the main app that is all copied from EEPROM into RAM at boot, this is surely not a satisfactory way of working because as soon  as the RAM starts overwriting the EEPROM, if the unit falls over/power is lost, the unit is bricked?

Please answer these questions directly and don't just point me back to source code. If there is documentation that explains this, then that's great I'm happy to read that.

Also, please answer the unanswered questions form the previous message.

Sorry to be a pest, but this is getting really very urgent indeed.

0 Likes

Folks,

Is it really asking too much to get a full answer to these questions?

0 Likes

Hi RoWo_4704901 ,

I am sorry for not giving a proper explanation. The problem is 20736 is a bit old chip and there is no single doc on programming spec for the CYW20732/36/37.

I will try maximum to get maximum inputs which help to clarify your queries.

1. For the factory programming , you need to use either our WICED SDK / Chipload.exe / a custom GUI app to download the initial hex of application code with UART / SPI / OTA FW upgrade option . This completely uses HCI UART. There is no other option to download the code for the first time. For this step refer to the blog here : Programming the TAG2/TAG3 Board using command line tools .

2. For the memory app architecture refer the blog here - BCM20732 Memory Map Architecture

3. When you include a FW upgrade option like UART/SPI/OTA - the EEPROM / flash memory is split such that there will be two sections . One for storing the current application and one for writing the new image. So that even if there is a power failure during upgrade process, the previous one will be retained.  As per my understanding all these options (SPI/UART/OTA FW upgrade) uses same memory divisions . Please refer to blog here - WICED Smart BCM92073X OTA Firmware Upgrade (1)  & WICED Smart BCM92073X OTA Firmware Upgrade (2)  You may need to concentrate on the sections - Section Change after Flash Download    , Section Change after OTA Firmware Upgrade  

4. If you need to retain the FW upgrade option even after first FW upgrade, then you have to make sure you have included the upgrade sections in the current application code as well.

5. Here the UART/SPI bootloader is as part of the application code. For example, if you refer to UART FW upgrade example in the SDK, the FW upgrade starts when the application receives a start command (WS_UPGRADE_COMMAND_START) .

As its an old chip and less documentation available, I am sorry , I would suggest you to go through the blogs which helps to clarify the details and then refer to the example application code available in WICED SMART SDK.

After going through the blogs, if its still won't clarify your doubts , please list it . I will try to explain it further.

Also I would recommend you to use OTA FW upgrade so that there will be less confusions for your development.

Thanks,

Anjana

Upon internal discussion it's not a trivial exercise to enable an SPI bootloader.

We highly recommend going down the OTA route to achieve what you need.

The link here provides guidance on how to add OTA Capability to the project, please have a review of this and the OTA examples in the SDK and let us know if you have further questions.

WICED Secure Over-the-Air Firmware Upgrade Application Note (SDK 2.x and TAG3 Board)

Thanks

Graham

0 Likes

Many thanks for both messages.

GrahamS_21   are you able to quantify - at all - what "not trivial" means in terms of how long this would take in comparison to OTA? I think the problem from our end is we'd need to write Android and iOS apps to do OTA, plus it would become a convoluted two-step process for a non-techy person, whereas if we did it via the processor attached to the BLE device it would be totally transparent to the user.

AnjanaM_61

I'm totally happy about point 1, that's not an an issue at all.

For point 3 you say: "the EEPROM / flash memory" would you clarify that the internals of the device are EEPROM? If so, where is this flash? Are you referring to an external flash chip on SPI or I2C? We do not have the latter.

In general though I am happy about it programming one area of EEPROM while keeping the previous area, that is great. I am hoping that somewhere in those blogs you pointed out it will describe the mechanism for switching from one area of EEPROM to the next when it is happy the new image is correct. I am concerned though in that it says "Section Change after Flash Download" when we have no flash (if I understand this correctly). I would greatly appreciate clarification on this.


For point 4, yes, that makes sense. We have exactly the same thing on our main micro.

0 Likes

Hi RoWo_4704901 ,

Q) For point 3 you say: "the EEPROM / flash memory" would you clarify that the internals of the device are EEPROM? If so, where is this flash? Are you referring to an external flash chip on SPI or I2C? We do not have the latter

A) I just said generally. In your case its EEPROM. Some 2073xx devices may connected to external flash as well. That's why I made a general statement.  It dos not matter if the NV storage is EEPROM or SF, the FW takes care of doing it right.

Q) "Section Change after Flash Download" - again even if its flash / EEPROM its the same mechanism. Don't bother about the terms. You can go through the content for the details and memory division.

In summary:

OTA update is the best option. It dos not matter if the NV storage is EEPROM or SF, the FW takes care of doing it right. If you want to go the SPI <-> micro route, yes, then have to follow the example of the UART upgrade. Your app only needs to handle the SPI transfers, and the ws_upgrade API should be able to handle the rest.

Regards,

Anjana

AnjanaM_61

Can I clarify please that this will work WITHOUT external EEPROM? If I try and run this on the TAG4 board with the EEPROM diconnected from the I2C pins on the BLE chip by using SW6, then nothing works.

We do not have external EEPROM on our board.

Thanks!

0 Likes

Hi RoWo_4704901 ,

It should work without External memory. Please check the below thread:

Re: FW Update without External Memory

Regards,
Anjana

ChunleiL_51 AnjanaM_61

I have had no luck programming a TAG4 board without external memory. If I disable I2C it won't even boot.

I have hooked up a scope to the I2C lines on my TAG4 board and it is clear it is using external EEPROM to store data when using the UART bootloader and it accesss the i2C bus at normal boot which makes me think it's fetching something from external EEPROM at power up too.

What makes you think this is possible without external memory?

I have looked through the souce code of the uart upgrade code and I can see nothing that suggests you can do without either extenal EEPROM  or external flash.It is possible I have missed something because it simply mentions EEPROM, not internal/external EEPROM. Are you absolutely possitive that EEPROM means internal EEPROM?

Thanks.

0 Likes

Hi RoWo_4704901 ,

I think I misunderstood your query previously .

If you are testing on Tag board, you need the EEPROM to be connected to test UART FW upgrade.

If you are using 20736S (https://www.cypress.com/documentation/datasheets/cyw20736s-bluetooth-low-energy-system-package-sip-m... ) as mentioned in your thread subject , then 20736S SIP has EEPROM on the package. So there you don't need any external EEPROM to be connected.

Regards,

Anjana

0 Likes

AnjanaM_61

OK, our actual board is, indeed, a 20736S. The TAG4 I was using to develop code because it's all too easy to brick the 20736S. Unfortinaely the I2C lines are not exposed on our board so if it gets its knickers in a twist, there is no way to recover the BLE.

0 Likes

ChunleiL_51

We have no access to the HCI UART from our micro. We have to open up the unit to access it, so programming it via HCI is a non-starter.

I'm hoping that Anjana is right and if we use the 20736S the UART bootloader will work as expected.

0 Likes

Hi RoWo_4704901 ,

Yes with 20736S you don't need any additional external memory.

Regards,

Anjana

0 Likes

Hi,

Sorry but I have to withdraw / rephrase what I said.

In further research, it's confirmed that TAG4 normally needs external memory to store and load program to RAM.

If no external memory is attached, then TAG4 will go into and stalls in Download Mode. In this case, if you still want to load program (without external memory), you can manually interact with TAG4 via HCI UART port, using WICED HCI commands to get your program transmitted through HCI UART port and loaded to RAM.

Just like what MiniDriver will do, and please refer to "Downloading the Application to RAM" in the following documentation:

https://www.cypress.com/design-guides/wiced-hci-uart-control-protocol

But this case needs a lot of work of modification, and the demo uart_firmware_upgrade wasn't designed to work like that so I withdraw what I said and you have to figure it out yourself.

To be more specific, If you didn't want to use external memory, you didn't need to mind UPGRADE / FW_UPDATE / OTA features at all because no programs are stored in the chip. Just reboot the board and make sure you send the newest program to RAM via HCI UART every time you reboot it, and then you will get the newest program running.

<<<<<<<<<<<<<>>>>>>>>>>>>>

Sincere regards from​ C. L.

<<<<<<<<<<<<<>>>>>>>>>>>>>

0 Likes