uart_tx api crashing issue

Hi, All

I try to modify the central uart example - mainly focus on uart function instead of BLE, I try to send a message back to uart use uart_tx() api instead of printk(), it seems working fine like this

 
    struct uart_data_t *buf = k_fifo_get(&fifo_uart_rx_data, K_FOREVER);
    
    if (uart_tx(uart, buf->data, buf->len, SYS_FOREVER_MS)) {
		LOG_WRN("Failed to send data over UART");
	}
	else {
		LOG_WRN("send data back to UART");
	}

But when I try to replace the uart_tx function with some message like below, and it keep crashing - reset

   
	uart_tx(uart, "UartDataRxed\n", 13, SYS_FOREVER_MS);
I wonder what I have done wrong with above, here is the RTT log message:
0> [00:00:00.025,787] <err> os: ***** BUS FAULT *****
00> [00:00:00.025,787] <err> os: Precise data bus error
00> [00:00:00.025,787] <err> os: BFAR Address: 0x2528206c[0m
00> [00:00:00.025,817] <err> os: r0/a1: 0x2528206c r1/a2: 0x00027b50 r2/a3: 0x20002300
00> [00:00:00.025,817] <err> os: r3/a4: 0x00000040 r12/ip: 0x00000000 r14/lr: 0x0001e533
00> [00:00:00.025,817] <err> os: xpsr: 0x21000012
00> [00:00:00.025,817] <err> os: Faulting instruction address (r15/pc): 0x0001e820
00> [00:00:00.025,848] <err> os: >>> ZEPHYR FATAL ERROR 0: CPU exception on CPU 0
00> [00:00:00.025,848] <err> os: Fault during interrupt handling
Thanks for your help!
Ping
Parents
  • Hi Ping,

    The string you're trying to pass is not of length 13, but rather it is length 14. Try to change it to 14 and see if it works!

    If it does not work, I would recommend you take a look at this NCS Course topic concerning UART to both read up on the essentials as well as examine if the sample in exercise 1 could explain what you're missing. Additionally, this uart echo sample might be of help

    Let me know if any of this helps! 

    Kind regards,
    Andreas

  • Hi, Andreas

    Thanks for your reply, I changed the length to 14, and it still crashes. don't think it is the length issue.

    I tried the ehco_bot sample, it is based on interrupt, and it works fine, thank you for sending it. The other sample uses uart_tx function too - not based on interrupt, so for me it has same issue. 

    Ping

  • Hi Ping,

    Apologies for the delay in response. The office has been closed due to the recent holidays. Have you figure out the issue since your last reply?

    If not, lets check out if the error you've pasted may help us. Could you open a command line window and write the following

    1) "where arm-none-eabi-addr2line"

    This should return something like 

    C:\Program Files (x86)\GNU Tools ARM Embedded\4.9 2015q3\bin\arm-none-eabi-addr2line.exe

    If it does not return something like this, then we can't do the next steps.

    2) We now want to know what causes the error you've pasted. Write now:

    arm-none-eabi-addr2line -e <path to _build\zephyr\zephyr.elf> <0xaddr>

    where you replace "<path to build>" with your path and <0xaddr> with the R15/pc and R14/lr adress

    "arm-none-eabi-addr2line -e <path to _build\zephyr\zephyr.elf> <0x0001e533>" for r15/pc

    and

    "arm-none-eabi-addr2line -e <path to _build\zephyr\zephyr.elf> <0x0001e820>" for r14/lr

    This should (hopefully) return a function or variable that could point to why the cpu has crashed. 



    Let me know about the progress.

    Kind regards,
    Andreas

  • Hi,

    PingISTL said:
    here is what I did, and cannot go any further - did I misunderstand you?


    You did it correct. This just means that gnuarmemb is not added to the your system variables, which we need to run the two other lines. If we need to/or you want to try this yourself while we look on the next possible solution, you could perform this step in the manual installation guide. It should allow you to run the two missing lines lines in the prior suggestion.

    PingISTL said:
    Thanks for your reply, I changed the length to 14, and it still crashes. don't think it is the length issue.

    Before we started the command line investigation, you said that your code still crashes. Have you changed anything else in central_uart than than line 162 illustrated as seen below? I am not able to recreate any error by simply editing that line. If your project does not contain any sensitive information, you could add the .c file you're working in by inserting it in a code-snippet in a reply, and I'll take a look.

    Also, I should have asked this question earlier: What version of nRF Connect SDK are you working with?

    ...
    
    // if (uart_tx(uart, buf->data, buf->len, SYS_FOREVER_MS)) {
    if (uart_tx(uart, "UartDataRxed\n", 14, SYS_FOREVER_MS)){
    	LOG_WRN("Failed to send data over UART");
    }
    
    break;

    Kind regards,
    Andreas

Reply
  • Hi,

    PingISTL said:
    here is what I did, and cannot go any further - did I misunderstand you?


    You did it correct. This just means that gnuarmemb is not added to the your system variables, which we need to run the two other lines. If we need to/or you want to try this yourself while we look on the next possible solution, you could perform this step in the manual installation guide. It should allow you to run the two missing lines lines in the prior suggestion.

    PingISTL said:
    Thanks for your reply, I changed the length to 14, and it still crashes. don't think it is the length issue.

    Before we started the command line investigation, you said that your code still crashes. Have you changed anything else in central_uart than than line 162 illustrated as seen below? I am not able to recreate any error by simply editing that line. If your project does not contain any sensitive information, you could add the .c file you're working in by inserting it in a code-snippet in a reply, and I'll take a look.

    Also, I should have asked this question earlier: What version of nRF Connect SDK are you working with?

    ...
    
    // if (uart_tx(uart, buf->data, buf->len, SYS_FOREVER_MS)) {
    if (uart_tx(uart, "UartDataRxed\n", 14, SYS_FOREVER_MS)){
    	LOG_WRN("Failed to send data over UART");
    }
    
    break;

    Kind regards,
    Andreas

Children
No Data
Related