NRF_LOG_HEXDUMP_* raises Data Access Violation Fault if a large buffer is used

Question

Hi to all, I have found that using SDK17.0.0 on NRF52832, whenever I try to use NRF_LOG_HEXDUMP_DEBUG for a large buffer (more than a 1000 elements), I get a Data Access Violation Fault. 
 I understand that since the NRF_LOG is deferred and my buffer is allocated in stack, I can get the buffer pointer to be corrupted. Aware of that, after calling the NRF_LOG_HEXDUMP_DEBUG I call the NRF_LOG_FINAL_FLUSH , in order to fully flush the logs. I have also changed the NRF_LOG_BUFSIZE to 4096, in order to fully store my buffer (1800 bytes) 
 
 I have also noticed that the output of my calls to NRF_LOG_HEXDUMP_DEBUG are capped at 80 bytes (8 columns x 10 rows), even if the buffer contains more data and and the length argument of the NRF_LOG_HEXDUMP_DEBUG call is more than 80 bytes. 
 
 Below is a code snippet. I have tried to dump the buffer immediately after creation (even if it is all zeroes), just to remove the possibility of errors in functions that manipulate the buffer contents. Still getting Data Access Violation Fault. 
 uint8_t cert_buffer[1800] = {0};
NRF_LOG_HEXDUMP_INFO(cert_buffer, 1800);
NRF_LOG_FINAL_FLUSH(); 
 
 Am I missing something or is this a bug? Can anyone reproduce this behavior? 
 
 Thanks in advance, 
 Pedro

ovrebekk · Accepted Answer

Hi Pedro 
 The developer looked into this some more, and found the issue. 
 Essentially the 32-bit header added to all hexdump messages is implemented as follows: 
 typedef struct
{
 uint32_t type : 2;
 uint32_t in_progress: 1;
 uint32_t severity : 3;
 uint32_t offset : 10;
 uint32_t reserved : 6;
 uint32_t len : 10;
} nrf_log_hexdump_header_t;
 
 The critical fields are offset and len , which are 10-bit values, effectively limiting a HEX dump to 1023 bytes in length. 
 In order to increase the limit to 4095 bytes you can change the struct to this: 
 typedef struct
{
 uint32_t type : 2;
 uint32_t in_progress: 1;
 uint32_t severity : 3;
 uint32_t offset : 12;
 uint32_t reserved : 2;
 uint32_t len : 12;
} nrf_log_hexdump_header_t;
 
 I have asked the team if we can document this limitation, and add a length check on the HEXDUMP API, but I can't guarantee if or when this will be implemented. 
 For now I hope the workaround above will suffice? 
 Best regards Torbjørn

NRF_LOG_HEXDUMP_* raises Data Access Violation Fault if a large buffer is used

Top Replies