• State Verified Answer
  • Locked Locked
  • Replies 4 replies
  • Subscribers 25 subscribers
  • Views 201 views
  • Users 0 members are here
Attachments (3) Download All
Nordic Case Info
  • Case ID: 285628
Options
nRF5 SDK is not maintained anymore
More Info: Consider nRF Connect SDK for new designs
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Organizing my project code

user74012

Hello,

I am running an ble_app_uart example from SDK 17.1.0 in SES on my nRF52-DK.

As great example as it is, I find it a bit non-practical for further development so I wanted to organize it to suit my OCD a bit better. So I created separate .c/.h files in my project, and cut-and-pasted all the ble, nus and gatt related functionality over there. Please find the files in the attachment, including my main.c.

The example ble_app_uart is modified in that, all init functions are wrapped inside the single one called mers_ble_init(), and after the init it just calls for idle_state_handle(). Additionally, the nus-handler stores the data from the smartphone app into the flash. 

The code builds and links, but the application fails after flashing the chip. According to my debugging, the initialization works fine, bit it enters the hard fault in the main loop. I cant figure out what went wrong, since the project replicates the original example and builds successfully. Did I organize my library properly?

Best, 

W

EDIT: issue is solved.

The reason was that I didn't intend to use UART as an user input so I deleted the uart_event_handle, and set 

APP_UART_FIFO_INIT(&comm_params,
                   UART_RX_BUF_SIZE,
                   UART_TX_BUF_SIZE,
                   0,
                   APP_IRQ_PRIORITY_LOWEST,
                   err_code);

When I brought back the original hander function, and instantiated UART_FIFO properly, it worked again.

Anyways, the builder didn't mind having not uart handler, but the application wouldn't work without it. Why is that so? How can I disable UART events and keep the BLE functionality? Why do we need the uart_event_handle, when all it does is to send some characters to NUS?

Parents
  • 0

    Hi Pero

    Moving all the BLE functionality into a separate file makes a lot of sense. I usually do the same when I develop larger BLE projects. 

    Anyways, the builder didn't mind having not uart handler, but the application wouldn't work without it. Why is that so?

    It's good to hear you found the issue. I checked the code, and it seems there is no checking to make sure that the event handler is set or not. If you set it to 0 it will simply be accepted by the init function, and as soon as some UART activity occurs it will try to call the event handler at address 0 which will lead to a hardfault. 

    If you don't need the UART functionality you can simply remove it altogether, by removing the call to APP_UART_FIFO_INIT, and any other code referencing the app_uart library. 

    Best regards
    Torbjørn

  • 0 in reply to user2116

    Hello Torbjørn, thanks for the answer!

    Well truth to be told, I want to use UART, but not as the input. I want to print out some status messages using retargeted printf function, so I need APP_UART_FIFO_INIT. 

    user2116 said:
    soon as some UART activity occurs it will try to call the event handler at address 0 which will lead to a hardfault. 

    Okay this makes perfect sense. But I never typed anything on UART port, so the handler should never have been invoked. And in the debugger-mode, the printf commands are executed without invoking the handler, that is, without crashing into the hardfault. So, how does the handler get invoked if nothing has been entered at the UART port?

    Second problem with the handler:  I have left the handler inside my code, but I commented out most of the code inside of it. So it was basically a function that does nothing, but at least it wasn't at the address 0. However, the application still ended up in hardfault, leaving me to think it is something else that causes the crash. 

  • +1 in reply to user74012

    Hi Pero

    Wesperos said:
    Okay this makes perfect sense. But I never typed anything on UART port, so the handler should never have been invoked. And in the debugger-mode, the printf commands are executed without invoking the handler, that is, without crashing into the hardfault. So, how does the handler get invoked if nothing has been entered at the UART port?

    What was the state of the RX pin? 

    If the RX pin is low for a long time it will trigger a break condition in the UART peripheral, which will be registered as an error and forwarded to the interrupt handler. 

    You will also get events after sending UART data, but if you haven't sent anything in the code this should obviously not happen. 

    Wesperos said:
    Second problem with the handler:  I have left the handler inside my code, but I commented out most of the code inside of it. So it was basically a function that does nothing, but at least it wasn't at the address 0. However, the application still ended up in hardfault, leaving me to think it is something else that causes the crash. 

    Didn't you say that you solved the issue by bringing back the handler?

    To figure out what caused the hardfault you could try using the debugger, and see if you can trace which functions lead up to the hardfault by looking at the stack trace. 

    Best regards
    Torbjørn

Reply
  • +1 in reply to user74012

    Hi Pero

    Wesperos said:
    Okay this makes perfect sense. But I never typed anything on UART port, so the handler should never have been invoked. And in the debugger-mode, the printf commands are executed without invoking the handler, that is, without crashing into the hardfault. So, how does the handler get invoked if nothing has been entered at the UART port?

    What was the state of the RX pin? 

    If the RX pin is low for a long time it will trigger a break condition in the UART peripheral, which will be registered as an error and forwarded to the interrupt handler. 

    You will also get events after sending UART data, but if you haven't sent anything in the code this should obviously not happen. 

    Wesperos said:
    Second problem with the handler:  I have left the handler inside my code, but I commented out most of the code inside of it. So it was basically a function that does nothing, but at least it wasn't at the address 0. However, the application still ended up in hardfault, leaving me to think it is something else that causes the crash. 

    Didn't you say that you solved the issue by bringing back the handler?

    To figure out what caused the hardfault you could try using the debugger, and see if you can trace which functions lead up to the hardfault by looking at the stack trace. 

    Best regards
    Torbjørn

Children
Related
Terms of service