Repeated SPI transfer hangs RTOS

Scott,

Thank you for your reply. I am not seeing the stack peak go beyond the stack size.

I have attached a screenshot below.

Thanks,

Priya

OK, thanks.

Can you also check the Hwi stack peak?  Click on the Hwi module, and the Module tab, and look at hwiStackPeak versus hwiStackSize.

If you click on the BIOS module, and the “Scan for errors…” tab, are there any other errors reported?

And if you reload the program and go to main(), is the LoggerStopMode error still indicated?  Or does that only happen after you’ve tried the SPI initialization?

Thanks,
Scott

Scott,

Thank you for your reply. I am attaching two screenshots. One is the BIOS ROV when the debugger halts in main. While I increased the task size of SBP from 644 to 900, I don't know if that created any memory overlaps among other tasks?

The second screenshot is the ROV after the program has been halted. As you can see I am getting an exception inside the Hwi module. The stack peak for this module is within the stack size (336 and 1024).

What does this exception mean and what to do about it?

Thank you,

Priya

I forgot to attach the screenshots. It seems to let me upload only one screenshot a post.

Here is the BIOS ROV halted in main screenshot.

Here is the Hwi module exception screenshot.

Thanks,

Priya

Priya,

OK, thanks.  I’ll be offline for a while, but in the meantime…

Increasing the stack size should not create any overlaps.

Just to double check… you can see the PC sitting at main() and still have the ROV errors?  I ask again because this is an important point.  Sometimes the PC will stop at the program entry point after loading, versus main().  At that point memory is not initialized, so ROV can indicate errors.  But at main() there should be no errors indicated.  

Are you building this app within CCS and then launching the debugger?  Or are you building it outside CCS, and then running it in CCS?  If it is the later, then sometimes errors can be shown in ROV if there is a mismatch between the environment where the program was built, versus the CCS debug environment.

The exception indicates undefined Hwi: 39.  This would correspond to a CRYPTO result available event.  Does that ring any bells?

In ROV if you click on the Hwi module Detailed tab, can post what that shows?

Thanks,
Scott

Good morning Scott,

I appreciate your reply. I put a breakpoint at PIN_init inside main.c and yes, I am seeing the same ROV errors. I am building and debugging from CCS6.1.2.

I have attached a screenshot of the detailed Hwi to this post for your feedback. I don't know anything about CRYPTO result being available. Could this be something happening in SimpleBLEPeripheral?

I went back to the default SBP task stack size of 644. I am not seeing any stack overflows for any task.

Thank you,

Priya

Priya,

Thanks for the additional info.

I don't think the CRYPTO interrupt is coming from SimpleBLEPeripheral.  If it was there should be an interrupt vector plugged, and it isn't shown in the screen shot you attached.

Were you seeing ROV errors before you started modifying the example?  Usually ROV errors mean memory corruption.  Or mismatched configuration.  If that has occurred due to some modification, it is possible that this is somehow contributing to the SPI transfer issue.

Regarding the transfer issue, and needing to do that in a UART read callback, that is really puzzling.  If it isn’t a stack overflow issue, I’ve run out of specific ideas.  

I think there were some SPI driver issues with early releases.  I don’t know about 2.13.00.06 specifically.  But I expect there may have been some SPI driver improvements in the last year.  I don’t know if these relate to the problem with needing to call from a read callback or not.  I will talk to our SPI expert about this tomorrow to see if he has any ideas...  

I also wonder if it would help for you to upgrade to the most recent TI-RTOS release (software-dl.ti.com/.../index.html) There are some necessary migration steps that came with the 2.15 release (processors.wiki.ti.com/.../TI-RTOS_Migration_2_15).  At this point I’m just wondering if that is a possibility for you…

Thanks,
Scott

Scott,

Thank you for your reply. My machine was upgraded to windows 10 and additional memory was installed on it to handle CCS and windows 10.

I also have always been seeing exclamation marks under the driver files that I have questioned (screenshots attached). I never had a problem opening any of these files inside CCS which is why I lived with it. I can go to a clean copy of SBP and see how I fare with the ROV.

I will be awaiting your driver expert's comments.

Thank you,

Priya

Hi Priya,

If you hover the mouse over one of the exclamation points is there a pop up message?

When I was referring to memory corruption it is for the target processor (CC2650) being debugged.  ROV will read and traverse data structures in target memory to create its data displays.  If data objects get overwritten (like with stack overflow, or out of bounds writing, …) then ROV reads corrupted data.  Sometimes there will be specific messages about data that is incorrect, other times the ROV displays get really messed up.  

ROV can also have difficulty interpreting the data it reads if the format of some of the data objects has changed.  For example, if a program is built with a newer version of TI-RTOS and is debugged in an older TI-RTOS environment.  That is what I’d referred to as “mismatched” configuration or environment.  If you are seeing exclamation marks over some files I wonder it this might point to a configuration issue.

I haven’t been able to talk to the SPI driver guy yet, I’ll get back when I have some suggestions…

Regards,
Scott

Priya,

I have to research the specific changes for SPI over the last year.  I’m pretty sure there are more recent BLE releases using the newer TI-RTOS releases.  But I’ll need to research this too.  

Also, the SPI person I’ve been trying to contact is out of office thru this week.  I will talk to some others tomorrow to see if I can get any more info/suggestions.

Regards,
Scott