Organizing my project code

Question

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?

user2116 · Accepted Answer

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

Organizing my project code

Top Replies