LwMesh OTAU Bootloader

[gc_lead]

Hi,
We are currently using the SAMD21 and the SAM4S microcontrollers  in our design of a zigbee network. The SAMD21 is used as our node/client and the SAM4S is used as our coordinator/server. We received a project from Atmel for a OTAU bootloader for the SAMD21 in IAR Embedded workbench. 

Our application is developed using Atmel Studio and the bootloader using IAR Embedded workbench. According to this document: http://community.atmel.com/sites/default/files/OTA%20Upgrade%20Guide.pdf, "Bootloader code ABI (Application Binary Interface) must match ABI used in main program. This means that Bootloader is compiler-dependent; the same compiler should be used for both Bootloader and application. At the moment only GCC version of bootloader is available. "

We are currently using different compilers for the application and bootloader and are having the issue that when performing an OTAU on 100+ nodes, we have 100% success the first try and 50% or less after the second try. This indicates to us that might be a bootloader issue.

Does having different compilers for the bootloader and application code could explain the issue we are having? Is there a GCC bootloader available for the SAMD21 microcontrollers?

Thanks,
gc_lead

[ataradov]

The appnote is for AVR system. There it is critical that BL and application are using the same ABI. This should not be a requirement for ARM. But there is no official port of that bootloader to ARM, where did you get yours?

This indicates to us that might be a bootloader issue.

I don't see how this is possible on ARM, especially with first round of updates working correctly.  Mismatch in ABIs will lead to a completely broken system.

Can you describe the nature of the failures? Partial writes? Corrupted data?

Does having different compilers for the bootloader and application code could explain the issue we are having?

Should not matter at all.

Is there a GCC bootloader available for the SAMD21 microcontrollers?

The system you are using was originally done for GCC.

[gc_lead]

Hi Alex,
We got the bootloader from Atmel for the SAMR21 which we updated to use the SAMD21.

Here is what we observed:
-we programmed our nodes using image V1.0
-after some time, we perform an OTAU to update to image V1.1 which success 100% of the time (tested in a network of 107, 149, 157 and 242 nodes)
- if we need to perform another OTAU in a section that was 100% success the first time, this succeeds only at a 15% to 50% rate. Even if we use image V1.1 or V1.0
-all OTAU attempts after that fails

The units are fully operational after an OTA failure. The nodes that updated successfully and those that did not updated seems to be fully operational and communicating with the coordinator correctly.

Here are the setting in the OTA server:
#define OTA_MAX_BLOCK_SIZE     64 //(Page alignment limit in D21 flash)
#define OTA_RESPONSE_TIMEOUT   60000            //Timeout to move to next client when sending unicast messages.
#define MAX_PROGRAM_SIZE      128512ul
#define FLASH_PAGE_SIZE      64

#define OTA_MAX_RETRIES        5

#ifdef BROADCAST_OTAU
#define OTA_BROADCAST_FRAME_SPACING      9000   
#define OTA_UINCAST_FRAME_SPACING           9000      
#define MAX_32_BIT_POSITION         32            
#define OTA_BLOCK_RETRY_SPACING 9000             
#define OTA_QUERY_RESP_TIMEOUT  11000
#define BROADCAST_ADDR          0xFFFF
#else
#define OTA_FRAME_SPACING      100
#define OTA_BROADCAST_FRAME_SPACING      OTA_FRAME_SPACING
#endif


What we see in the serial output is that queries are being sent to the nodes but no replay is received from the nodes. This is an example of what we see during the OTAU:
------ OTA_QUERY_REQ_SENT_STATUS Client Addr: 0x0af2 Status: Success
------ OTA_QUERY_REQ_SENT_STATUS Client Addr: 0x0291 Status: Success
------ OTA_QUERY_REQ_SENT_STATUS Client Addr: 0x21bd Status: Success
------ OTA_QUERY_REQ_SENT_STATUS Client Addr: 0x71e6 Status: Success
------ OTA_QUERY_REQ_SENT_STATUS Client Addr: 0x46b7 Status: Success
------ OTA_BLOCK_RETX_SENT_STATUS Client Addr: 0x46b7 Status: Success
------ OTA_QUERY_REQ_SENT_STATUS Client Addr: 0x46b7 Status: Success
------ OTA_SWITCH_REQ_SENT_STATUS Client Addr: 0x46b7 Status: Success
------ OTA_QUERY_REQ_SENT_STATUS Client Addr: 0x2fbe Status: Success
------ OTA_QUERY_REQ_SENT_STATUS Client Addr: 0x76a4 Status: Success
------ OTA_QUERY_REQ_SENT_STATUS Client Addr: 0x60bb Status: Success
------ OTA_QUERY_REQ_SENT_STATUS Client Addr: 0x29b5 Status: Success
------ OTA_QUERY_REQ_SENT_STATUS Client Addr: 0x2083 Status: Success
------ OTA_QUERY_REQ_SENT_STATUS Client Addr: 0x7e9d Status: Success
------ OTA_QUERY_REQ_SENT_STATUS Client Addr: 0x0428 Status: Success
------ OTA_QUERY_REQ_SENT_STATUS Client Addr: 0x2da2 Status: Success
------ OTA_QUERY_REQ_SENT_STATUS Client Addr: 0x5fe8 Status: Success
------ OTA_QUERY_REQ_SENT_STATUS Client Addr: 0x0b7a Status: Success


Thanks,
gc_lead

[ataradov]

I'm not familiar with that specific port of the bootloader.
This is a very complex issue and some debugging will be required. Since you can confirm that new image is fully operational, there is no reason for the consequent failures other than network load.

You need to keep in mind that after the update, nodes reset and lose all routing information. So it takes time to get the network back after the full reset. That's the only high level advice I can offer.

You would need to setup a sniffer and check what's going on exactly when this happens.

[gc_lead]

Hi Alex,
Thank you for your answer. We are in the process on doing some testing and collect network traffic data using a sniffer. More info after the test is completed.

Question: for the SAMD21 ARM microcontroller, should we clear and set the EIND register? I have not been able to find the answer to this but in the bootloader code we have from Atmel, I see the following:
static inline  void jumpToApplication(void)
{
#if (defined(ATSAMR21E18A) || defined(ATSAMR21G18A))
  uint32_t appEntryPoint = *(uint32_t *)(0x3FFC0UL);
  void(* startAddress)(void) =(void(*)(void))(*(uint32_t *)(appEntryPoint + sizeof(uint32_t)));
  __set_SP(*(uint32_t *)appEntryPoint);
#endif
  // nulling extended indirect register for indirect call out memory
  CLEAR_EIND();
  startAddress();
}

CLEAR_EIND() is called in the jumpToApplication function but SET_EIND is never called. No sure what this macro does in IAR: #define CLEAR_EIND().

Thanks,
gc_lead

[ataradov]

CLEAR_EIND() is AVR thing, you don't need it on ARM. But if everything compiles, it is probably defined as noting anyway.