LAUNCHXL-CC3235SF: CC3235SF sl_Send() not allow to send data more that 395 bytes

Hi,

This looks like stack overflow. Where is your TxData buffer located? It is global or at stack?

There is not such limitation like 395 bytes send via sl_Send() API only.

Jan

Definitely,No. Of course, I checked both cases global define of static size array and using function to allocate memory in HEAP result is same. As you can see on picture  we have a lot of free memory. It's not related to memory, because trouble haven when I send data in array with size 512 bytes as well as size of array is 1024, result is same. Clear that if I have low memory size then in compilation 1024 will be error, but memory space is enough

Hi,

Image from memory allocation does not proof anything. You have plenty of RAM not allocated into memory sections. But if there will not be enough space during runtime (heap, stack) this free RAM will not be uses and your code will fail with insufficient memory. Just for a test try to increase size of .stack section at linker (*.cmd) file.

It is hard to say why your code is failing. At first step you should determine if there is a hard fault. If so you can continue with common techniques how to debug hard fault at Cortex-M MCUs.

Jan

I increase size of stack & heap  but it not effected to allocation process for my array ( of course  I see changes on Chart Memory Allocation, but performance of my array still same =395 bytes)

--stack_size=0x4000  //0x1000
--heap_size=0xC000 //0x8000
--entry_point=resetISR
--diag_suppress=10063 /* suppress warning about non _c_int00 entry point */

Hi,

In addition to checking the size of the stack and heap, you should also check the full running state of the RTOS to ensure there isn't memory corruption due to another reason such as a bad pointer reference.

I suggest you use the ROV debug tool to inspect the state of your RTOS and ensure that there isn't any memory corruption or other bad state reported. See my instructions here for guidance: https://e2e.ti.com/support/wireless-connectivity/wifi/f/968/p/733294/2707429#2707429

Regards,

Michael

Thank Michael, but I use TI example without RTOS. Its not my code just I put Send() function in existing example. 

Hi,

Ah yes, I missed that you were using the nortos variant of the trigger_mode demo. This will make debug more difficult unfortunately.

Have you tried using the debugger to step info the sl_Send() function and see which precise line causes the crash? Knowing exactly where the crash occurs will be useful for determining how to fix the issue.

Also, other than the sl_Send() change, did you make any other changes to the trigger_mode example?

Regards,

Michael

Ha ha , I told you it's example from SDK, but this example use trigger low power mode for RX by TCP, so that I think maybe in this mode exist some limits to TX packet size, but not found any explanations. It reason for make this topic. In attachment current project,a little different to initial example, but you can see that network core is same. I was paste two fprint() before and after sl_Send() to catch trouble in debug process, event of crash happen after or during  data send because I seen incoming data at PC soft, last printf never seen(if size of array more 395 bytes)trigger_mode_CC3235SF_LAUNCHXL_nortos_ccs (8).zip

Hi,

Thanks for providing your code, I took your changes, added it to a new trigger_mode nortos project and rebuilt + ran it on my CC3235.

I didn't encounter the issue at exactly 396 bytes for sl_Send, but setting the SizeTxData to 1024 causes the issue to occur.

Checking the faultstat registers, it doesn't appear that the device entered a hard fault condition. You can see this thread here for what I'm referring to by faultstat register: https://e2e.ti.com/support/wireless-connectivity/wifi/f/wi-fi-forum/865780/cc3200-launchxl-cortex_m4_0-trouble-reading-memeory-block/3210205#3210205

Digging deep with the debugger, it seems that one of the low level functions _SlDrvMsgWrite() is where the sl_Send ends up right when the code gets stuck. Specifically, it appears that it jumps to a random address right at line 1171 of driver.c, at

if ((pCmdExt->TxPayload1Len > 0) && (pCmdExt->TxPayload2Len > 0))

So, it does look like might be some memory corruption at hand. Can you double-check your pointer operations, and ensure there isn't anything in them that could cause memory to be incorrectly written?

Regards,

Michael

Michael,

you right if used sizeof () then problem maybe happened if forget about dimension of word, but in this software all buffers for TX set in bytes in this case size of word=1. This issue must be addressed to developers of SDK, because behavior of MCU look like low level bug.

Hi Dmitry,

I quick looked into your code. It looks that you are using goto by very creative way ad from this reason is your code very hard for understanding. As I saw your code I am even more convinced that bug is hidden somewhere inside your code. Unfortunately I am not able say where is it. I agree with Michael that you should check your pointer operations.

Jan

Jan, if you confused  by my code then take fresh example from TI and implement Send(), result will be same. 

Hi Dmitry,

Can you try using the power_measurement nortos example from the SDK? As part of the demo functionality, it performs sl_Send() with a payload size of 1000B. If that sl_Send works, then the issue lies somewhere in your code, and not with the Wi-Fi host driver or NWP code. This will be useful to narrow down the scope of the issue.

Regards,

Michael