In my case, 1. Initially, issue was very consistent. 2. Then, I went about coding features, with assumption that I will resolve issue later. Infinite loop issue become infrequent. 3. I have resolved one memory related issue recently. It was similar to Richard's suggestion (+1 on memory allocation for string functions). 4. I haven't seen infinite loop issue in last 2-3 days. Lets...
2013-05-25 22:53:08 PDT by perivr
As was mentioned, the most likely cause is that the heap has been corrupted by accessing out side the bounds of a heap object (perhaps forgetting to +1 the value of strlen when allocating blocks on the heap). The other possibility is that the heap has been corrupted by multi-threading issues. One big one would be calling them from ISR routines (the heap_# routines are thread safe but not ISR...
2013-05-25 18:14:54 PDT by richard_damon
Hi, I have the same problem as Perivr, but running on a PIC32MX575F512H. 32768 bytes of heap, of which about 5K are still free when this happens. I am trying to allocate a block of only 96 bytes. For testing, after I found this topic, I have compiled with heap_3.c instead of heap_4.c and I get a general exception caught with the function _general_exception_handler, but a lot later. Type...
2013-05-25 16:55:18 PDT by smmg
The SL product, being Super Lean, only supports a single volume, so the simple answer is no, it is not possible. To have multiple drivers you would probably need either the THIN of high performance sister products, but neither of those are open source so you would need to contact HCC directly to get a quotation. You may also be able to use the open source Chan FATfs product, which is open...
2013-05-25 10:27:55 PDT by richardbarry
Hello, Is it possible to use multiple hardware drivers with FAT SL? I have a SDmicro-card (SPI) and a USB-flashdrive connected to a PIC32. I need to be able to copy files between these two drives. If FAT-SL does not support this, is there an embeeded FAT32 filesystem that does? Thank you! Marcel.
2013-05-25 09:58:59 PDT by hermarcel
Forgot to say if you leave the xHigherPriorityTaskWoken parameter NULL then you have no way of knowing if calling the function caused a higher priority task to unblock or not. It is only meant as an optimisation that can be used when you know that a context switch is never needed. Regards.
2013-05-25 05:42:03 PDT by richardbarry
Also ensure configIDLE_SHOULD_YIELD is set to one in FreeRTOSConfig.h, otherwise if the idle task is running it will continue to run until the next tick interrupt occurs. Regards.
2013-05-25 05:32:29 PDT by richardbarry
OK ... looks like its a issue with value of "higher_prio_task_woken". I'll have to walk through and check all the code to make sure I haven't missed any execution steps or that the value of "higher_prio_task_woken" is not being overwritten somewhere but forcing the issue by using portEND_SWITCHING_ISR(pdTRUE); at the end of the interrupt fixes the problem...
2013-05-25 02:42:15 PDT by tomwbarclay
Thinking about the scheduling points... given that the only task available to run (ie not blocked) is the one task that was running, then would the call portEND_SWITCHING_ISR(pdTRUE) at the end of the interrupt force the same task to be re-scheduled ? Its not after all a higher priority !!! or is the label of the variable "higher_prio_task_woken" misleading ? and a task of the...
2013-05-25 02:34:24 PDT by tomwbarclay
DaveDoors, In the interrupt routine there is 1) ... higher_prio_task_woken = event_ISR_signal(* txfr_complete); // signal data ready then on exit 2) ...portEND_SWITCHING_ISR(higher_prio_task_woken); Just out of interest, in FreeRTOS 7.3.0 the 'higher_prio_task_woken' can be set to NULL. What would be the impact ? ... Tom.
2013-05-25 02:20:48 PDT by tomwbarclay