Hi,
I am using the DSPS sample code with the Basic Kit as my starting point and added a few simple lines of code to receive different message types from the phone DSPS app.
The phone sends different message types to the Basic Kit. Below is the code snippets of the function I made code changes in user_sps_scheduler.c to detect the message types:
static void uart_tx_callback(uint8_t res)
{
static uint8_t size=0;
uint8_t *periph_tx_ptr = NULL;
NearEyeProtHdr *hdr = (NearEyeProtHdr *)periph_tx_ptr;
//function gets called from uart transmit isr or application when its not running
switch(res)
{
case UART_STATUS_OK:
//get data and pointer
size = user_periph_pull(&periph_tx_ptr, size);
break;
case UART_STATUS_INIT:
size = user_buffer_read_address(&ble_to_periph_buffer, &periph_tx_ptr, TX_CALLBACK_SIZE);
break;
default:
ASSERT_ERROR(0); //error: callback called from unknown source
}
//if there is data available, send data over periph
if(size > 0)
{
// determine if the data in the periph_tx_ptr is "Text" to be display in QPI
// or actual QPI commands by looking at the message type in the header
switch(hdr->msgType)
{
// this is a text or speech from the phone
case 1:
// this is a phone number or SMS
case 2:
break;
// this is a QPI command to QPI
case 3:
break;
default:
break;
}
// skip the NearEye protocol header which is the first 5 bytes to get to CI msg
// send the CI message over to UART to QPI. For now, we are not going to try
// sending to the particular QPI specified in the protocol header
uart_sps_write(periph_tx_ptr+sizeof(NearEyeProtHdr), size-sizeof(NearEyeProtHdr), &uart_tx_callback);
return;
}
/ /我没有数据n the buffer so the callback is done
callbackbusy = false;
}
neareye_protocol.h file has this content:
#ifndef _NEAREYE_PROTOCOL_H_
#define _NEAREYE_PROTOCOL_H_
typedef struct {
uint8_t msgType;
uint8_t qpiSelect;
uint8_t brdSelect; // not used in current design
uint8_t resv0; // reserve future use
uint8_t resv1; // reserve future use
} NearEyeProtHdr;
#endif // _NEAREYE_PROTOCOL_H_
Keil compiled and built a new hex binary with optimization level set to 0. When I started the debugger and set a break point at line if (size > 0), it hit the break point when a message was sent to . size has a value of 0x10. However, stepping over to the next line of code will skip over this block message detection check and landed in callbackbusy = false;
I have tried a few different ways with no luck. I also tried flashing the modified code thinking when the board came up, it would boot from flash and this is what I will be debugging event though I know for sure that when running the debugger, the debugger will load the code directly into SRAM and execute.
If you know why, please let me know. or if you don't mind, can you check out the code I have really quick with your setup and you will see what I am talking about. Maybe it won't happen for you because you setup environment might be different than mine.
Thanks,
--Khai
Hi kqtrinh,
I ve tried what you have mentioned, just applied the code that you ve pasted on the post and set the optimization level to -O0 i can set breakpoint in the switch case block and in the uart_sps_write() and for every character i send i can step into the additional code. Have you placed breakpoint in the additional code (in the switch case or at the uart_sps_write) if you placed a breakpoint only at the callback = false line perhaps you are watching an additional invocation of the uart_tx_callback() (the first time the function was called it returned from the if(size>0) and perhapas there was a second time invocation of the uart_tx_callback where there the size was 0 so the function returned with callback = false).
Thanks MT_dialog
That's what I was afraid you would say. I inserted the break point at if(size>0) and tried to step into the switch {} block. I realized there were 2 invocations of this function per message sent from the phone.
One thing I notice here is that while I am in debug mode, setting a break point on any lines inside this switch block of code will result in the break point being greyed out with an exclamation point in it. This tells me that the code will not be reached when it runs. The only line that I am able to set a break point on is:
uart_sps_write(periph_tx_ptr+sizeof(NearEyeProtHdr), size-sizeof(NearEyeProtHdr), &uart_tx_callback);
So somehow any new code I added to the DSPS code base will not be recognized. So far that's the only place I mucked with. Since the current switch statement does nothing really, uart_sps_write() was called and wrote the characters out to the terminal no problem with or without adding the pointer offset sizeof(NearEyeProtHdr).
Also there is a message I sent from the phone that triggered HardFault_HandlerC() in hardfault_handler.c. Was it something in the byte stream I sent over that caused this?
Thanks,
--Khai
I did notice one thing. When building the code, with or without the switch block of code results in
Program Size: Code=15336 RO-data=2424 RW-data=72 ZI-data=10200.
Does that make sense? I would have thought the Program Size should be different with the addition of the switch block.
Thanks,
--Khai
I also compared the built HEX file with and without the switch block of code. There were differences but the file length (size) is identical. Shouldn't the hex file size for the one with the switch block be more than the one without as there should be more instruction lines of code generated and thus the hex file size should be larger?
Thanks,
--Khai
Hi kqtrinh,
断点是灰色的,这一事实means that the code that you have inserted is compiled out from the .hex file that keil is generating, this can be aslo verified by the fact that the size and the data from both of your compilations has the same size. That leads me to the conclusion that the optimization of your code is not -O0, the switch case should be excluded from your build when more than -O0 optimization is used (since you have mentioned that you ve changed the optimization level - i suppose that you went to "target options" choose "C/C++" tab and changed the optimization from there) have you compiled again the program ? I can get the results that you mention when optimization is larger than -O0. Also the program size that you mention is quite smaller than the one that i am getting with no optimization. Regarding the hard fault there are numerous reasons for an ARM to reach that point, unalligned access to memory etc.
Thanks MT_dialog
Weird. I checked the optimization level just now and it was set to -O3. I selected -O0 few days ago not sure why it went back to -O3. It is working now and definitely make sense that the switch block of code was optimized out since it's really didn't do anything just yet.
Thank you for baring with me.
--Khai