Secure DFU without Flow control (SDK 15.2)

RE: Secure DFU without Flow control (SDK 15.2)

bjorn-spockeli — Fri, 08 Feb 2019 15:57:15 GMT

As suggested by my colleague in this case, we were expecting the opposite behaviour, i.e. that you would need a longer delay with increasing baudrate. We kindly ask you to use the hardfault handling library to identify the cause of the hardfault in the bootloader.

We would also like to see traces of the UART lines during the transfer so that we can verify that the data is transferred correctly.

RE: Secure DFU without Flow control (SDK 15.2)

Goudra — Wed, 06 Feb 2019 19:59:34 GMT

Hi,

Is there any suggestion on this?

Regards,

Basava.

RE: Secure DFU without Flow control (SDK 15.2)

Goudra — Fri, 01 Feb 2019 14:59:13 GMT

Hi,

Now i'm sending data at 9600 baud rate using nrfutils command from the Prompt. Its working. But we have implemented same in St controller side(C code), here we saw same issue with hardware fault.

Then we log the working CMD prompt data, we observe the log packet by packet. While sending Firmware packet, after every 3 packet its need 200msec delay. (I really dont know why this delay is needed after 3packet?).

So, we considered it in our code and implemented it. Now issue got resolved. We struggled a lot to find out this and took 2 week of time.

To verify that delay, we tested with different baud like 4800. Now it is taking 400msec after every 3 packet.

and for 14400baud it is taking ~150msec delay.

I request you, Can you please let us know why the bootloader needs a delay after 3 packet? and

why the delay is changing based on the baud rate?

Because of this delay requirement some time its not working with 57600baud.

please find log file above "" Baudrate_9600.htm ""

Please let us know the delay requirement.

Thanks ,

Basava

RE: Secure DFU without Flow control (SDK 15.2)

bjorn-spockeli — Thu, 31 Jan 2019 16:17:53 GMT

Can use the nRF5_SDK_15.2.0_9412b96\examples\dfu\secure_bootloader\pca10040_uart_debug instead and attach the RTT log output? I would like to see the debug log of the bootloader code.

current_object is only modified in nrf_dfu_obj_op() so the issue must lie in the request handler chain. The request (nrf_dfu_request_t ) originates from nrf_dfu_serial_on_packet_received() in nrf_dfu_serial.c so maybe there is something that goes wrong there. Can you set a breakpoint there or print the nrf_dfu_request_t request.select.object_type field to verify that the received packet is parsed correctly.

As far as I can see this variable, request.select.object_type isnt modified in the calls from nrf_dfu_serial_on_packet_received to nrf_dfu_obj_op()

RE: Secure DFU without Flow control (SDK 15.2)

Goudra — Tue, 29 Jan 2019 16:57:48 GMT

Hi,

We used different example to build our bootloader. We used "secure_bootloader_uart_mbr_pca10040 " pca10040_uart example.

I tried to upload my Fw file from the command prompt using 9600 baud and without flow control. Its uploading properly. Below attachment shows LOG file. As in the log file, after every 3 FW packet it is taking 200msec delay.

devzone.nordicsemi.com/.../Baudrate_5F00_9600.htm

Same Flow I have implemented with C code to send my FW file. But after updating 12k or 16k bytes . I'm not getting reply from the Bootloader. I traced it and it is in hardware fault.

1. So to avoid this hardware fault i have increases the delay to 1sec between each 64bytes packet. Still it went to hardware fault.

2. Then I reduced the each packet size to 32bytes and kept 1sec delay in between Tx packet. For this configuration also i'm not getting CRC. I traced it. but it is a different issue now. I found issue in the below code.

As in the LOG, before sending initialization packet, Object will be selected as 1 ie NRF_DFU_OBJ_TYPE_COMMAND and current_object will update with 1 and init data should send after this.

Same way, to send FW packet, we need to select and create object with 2 ie NRF_DFU_OBJ_TYPE_DATA. Now current_object become 2 and start sending FW packet using opcode 0x08.

After sending some packet current_object becomes 1 . But i didn't change the obj number still the current_object value is modified. I really dont know how it is changed.

To check this i have created global variable to store this value. After some time variable value becoming zero. So some values are overlapped it and changed the value.

To make sure this overlapped issue, I have created the global arry with 500byte and the created the global variable. Then followed the updating procedure. After sending some FW packet array value and global variable value become Zero current_object value changed to 2 to 1.

Because of this, code will consider FW packet as init packet and later it will give invalid parameter error.

Please help me to understand what is going wrong.

static bool nrf_dfu_obj_op(nrf_dfu_request_t * p_req, nrf_dfu_response_t * p_res)
{
/* Keep track of the current object type since write and execute requests don't contain it. */
static nrf_dfu_obj_type_t current_object = NRF_DFU_OBJ_TYPE_COMMAND;

if ( (p_req->request == NRF_DFU_OP_OBJECT_SELECT)
|| (p_req->request == NRF_DFU_OP_OBJECT_CREATE))
{
STATIC_ASSERT(offsetof(nrf_dfu_request_select_t, object_type) ==
offsetof(nrf_dfu_request_create_t, object_type),
"Wrong object_type offset!");

current_object = (nrf_dfu_obj_type_t)(p_req->select.object_type);
}

bool response_ready = true;

switch (current_object)
{
case NRF_DFU_OBJ_TYPE_COMMAND:
nrf_dfu_command_req(p_req, p_res);
break;

case NRF_DFU_OBJ_TYPE_DATA:
response_ready = nrf_dfu_data_req(p_req, p_res);
break;

default:
/* The select request had an invalid object type. */
NRF_LOG_ERROR("Invalid object type in request.");
current_object = NRF_DFU_OBJ_TYPE_INVALID;
p_res->result = NRF_DFU_RES_CODE_INVALID_OBJECT;
break;
}

return response_ready;
}

Regards,

Basavanagouda

RE: Secure DFU without Flow control (SDK 15.2)

bjorn-spockeli — Tue, 29 Jan 2019 10:06:13 GMT

Great! Happy to hear that you're able to perform DFU with nrfutil with baudrate set to 9600.

Could you use the debug version of the serial bootloader for the nRF52832? You can find it in nRF5_SDK_15.2.0_9412b96\examples\dfu\secure_bootloader\pca10040_uart_debug.

Use Segger RTT Viewer or see the RTT output in the Debug Terminal if you're using Segger Embedded Studio. Please attach the log output to this question. It will hopefully provide some information to why the Hardfault occurs.

RE: Secure DFU without Flow control (SDK 15.2)

Goudra — Tue, 29 Jan 2019 05:09:55 GMT

Hi,

Thanks for the reply. I have tried with 9600 baud rate with nrfutil. Its taking around 50 sec to upload and it updated properly.

So same thing i have implemented C code to transmit FW packet to BLE. I'm making 64 bytes of packet of 4 bytes and sending it to BLE. It receiving properly. After sending 4k asking for CRC. I'm getting CRC.

I'm facing issue here.

1. After sending 4 or 5 4kbytes packet. Bootloader code going for Hardware fault.

2. I'm not understanding this issue. It will update the FW using CMD prompt nrfutil commands.

3. But with my code it is going for Hardware fault.

Is there any delay required for each packet?

What will be the reason for this hardware fault issue?

Please let me know the suggestions.

Thanks

RE: Secure DFU without Flow control (SDK 15.2)

bjorn-spockeli — Fri, 25 Jan 2019 15:42:35 GMT

Hi Goudra,

We have seen buffer overflow issues with previous SDK versions and the serial BL examples are designed with HWFC in mind. Can you try to lower the baudrate to 9600 and see if get any error with this configuration?

Best regards
Bjørn