![]() ![]() Debugging Toolsĭebugging is done typically over the same link as the program image download. See the development tool documentation for available options. Usually the target download is done over an RS-232 serial interface, although parallel interfaces, USB, and Ethernet are becoming more popular. After the application is compiled, linked, and located on the host, it is downloaded to the target hardware for execution. That is how the API is specified and not to be confused with normal memory allocation.In this article Host Considerations Computer TypeĮmbedded development is usually performed on Windows PC or Unix host computers. So specifying a stack depth of 100 will allocate 100 stack variables, which is 400 bytes. When you define a stack size it is in stack units, and on the STM32 each stack variable is 32 bits. When you are defining a stack size of a heap size, the number is the number of ints so the number of bytes is 4x that What heap file are you using (heap_1,2 or 3). That is just C code behaving like C code. If you allocate 400 bytes, it will give you 400 bytes. If you allocate 5 bytes it will give you five bytes, which fit in two 32 bit words with 3 bytes left over (to make up the second 32 bit word). If you allocate 4 bytes it will give you 4 bytes, which happen to fit in a 32 bit word. It just expects the compilers being used to comply with the C standards. I assume from what’s been said, FreeRTOS is very neat with how it uses memory and it somehow packs chars within a long for queues.įreeRTOS does nothing clever. Byte bytes that are left over in the 32 bit word will not be used. If you reserve a two byte array it will place it in two bytes of a 32 bit word. If you reserve a byte, it will place it in a 32 bit word. The STM32 is a 32 bit machine and as such required 4 byte alignment. Your problems sound to apparently random and like the linker script or the start up code is not configured correctly, unless it is just a plain old bug in your code.īecause reserving a byte on the STM32 seem to take up a long If you are using heap 3 with full malloc and free functionality and not freeing memory after allocating it at run time then you’ll blow up also.Īre you using stack overflow protection? What is the structure of the data you are posting around in the messages?Īre you using vApplicationIdleHook – that’s really useful to see if you system is locking up somewhere as this is only serviced when there is nothing for the OS to handle.Īre you clearing the interrupt pending bit inside the interrupt handlers? If that bit remains set then as soon as the interrupt is complete it will run again and again – this can also lead to a hard fault. when you are defining a stack size of a heap size, the number is the number of ints so the number of bytes is 4x that. I also found the size of bytes and ints a bit of a struggle to figure out. Point a break point in there and see if ever happens. If it can’t alloc what it needs, it will call the vApplicationMallocFailedHook (assuming you’ve enabled it). It uses that to create your stacks and Queues (btw, I meant to ask for an example of the xCreateQueue call). In FreeRTOSConfig.h you allocate heap for the OS. When I looked at where FreeRTOS had crashed when it hit a HardFaultException, it was usually the same task, but not always.ĭo you have a build map that shows the RAM and Flash usage for your project? I have found the HardFaultException was usually a bad pointer or bad array use – it did not ever seem to be related to the RTOS. XTaskCreate(ProcessKeys, ( signed char * ) “Process Capacitive Keys”, PROCESS_KEYS_STACK_SIZE, NULL, mainProcessKeys_TASK_PRIORITY, NULL ) I assume from what’s been said, FreeRTOS is very neat with how it uses memory and it somehow packs chars within a long for queues. I think it’s a fair question to ask about longs v bytes, because reserving a byte on the STM32 seem to take up a long. I have also had situations where it would crash as soon as the scheduler was started unless I did something like reduce the size of the stack in a thread to free up an extra bit of memory. Once this mode is entered, code that is not normally executed is called, so I assumed I was overflowing its stack increasing its stack size brings the other problem back where it crashes on a keypress, which made me think I was right on the edge of code usage. What I did was remove the USB code as it’s not often used in normal operation and it went from crashing once a key is pressed to not crashing unless you go into “set-up mode”. I think it’s RAM because removing a task took it from crashing to not crashing (with a HardFaultException). Thanks for the replies and and sorry for the delay in replying, I didn’t get a notification of a reply.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |