First of all I have sleep mode disabled in user_config.h with
const static sleep_state_t app_default_sleep_mode = ARCH_SLEEP_OFF;
and set user_periph_setup.h with
// using SW flow control instead of HW flow control here
#define CFG_UART_SW_FLOW_CTRL
#undef CFG_UART_HW_FLOW_CTRL
1. Start the debug session in Keil by clicking the RED d button at the top of the IDE toolbar which loaded the DSPS code into SRAM on the DA14580 board
2. Code run to SystemInit. Click the run icon at the top or F5
3. Launch the DSPS app on the phone which scan for the DA14580
4. Should find the device. Now select it to begin sending text to it either with the Console tab or the Tx/Rx tab
5.我想to know the flow of the application. So I put a break point in file user_sps_scheduler.c in function uart_tx_callback(). It will break at this line when a text comes in and before it goes out to the Terminal
6. Send the text. The break is hit.
7. My problem is here. When I tried stepping through the code a line at a time, it didn't work. The program counter jumps all over the place unpredictably which I can't really follow. Please help!!! But if I were to quit stepping the code and just click on run (F5), I will get the text string displayed on Tera Terminal. But then, at this point, my phone connection to the DA is lost.
Thanks,
--Khai
Hi kqtrinh,
When you are issuing a breakpoint while the fw is running and while you are connected, this breakpoint will insert a small delay, that small delay will cause the connected devices to disconnect, since the BLE protocol needs syncronization in order for a connection to be established (with that small delay the device will send a connection event later in the predefined time so it will not get the TX event of the master therefore will consider that the connection is lost). Now if this can happen by only inserting a breakpoint, imagine what will happen if the breakpoint hits and the ARM needs your intervention to keep on processing the events. Regarding the jumps of the code in general the BLE stack is located in the ROM code that means that the scheduler in the ROM code sends events and the application (in your case DSPS) and the SDK handles it, so you will have to get familiar with the handlers and events of the system, if that are the jumps that you mean. If by running the code you see that the specified function doesn't go sequentially through the code thats because of the optimization that keil does. In keil, at the "Options for Target" and then in the "C/C++" tab change the optimization level to -O0 or -O1 this will improve things and you will be able to follow the code.
Thanks MT_dialog
Thanks for the prompted respond. Setting Keil optimization to level 0 fixed it.