Hi All,
I have implemented the code for MASTER serial DFU in ST micro controller. which can send the app .bin file. I'm using 57600 baud and disable the flow control.
I'm getting Unexpected OP_CODE error. Is it because of data loss?
Can we send data without setting Hardware flow control? Because in our custom board don't have Hardware flow control pins.
How we can achieve proper communication between BLE devices and ST uC?
Any baud rate issue?
Please let us know any suggestions.
Thanks,
Basava.
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
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
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.
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.
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
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()
