I’m using a TI Hercules RM46x MCU The compiler is TI v5.2.2 I’m using FreeRTOS 8.2 I have been able to execute several standard (FreeRTOS provided) demos My question has nothing to do with a demo project I’m trying to integrate FreeRTOS+UDP V1.0.4 into a kernel and I’m having trouble with the software timers. The UDP timer task creation call hangs and the debugger will not step into the code so that I can see what is happening. I moved the call to the timer creation to before the call to start the kernel scheduler and that worked OK. However, when stop timer is called the code execution again hangs and I cannot step into it using the debugger. When I pause the debugger, the code is executing in the interrupt assembly file. I’m reasonably sure the issue is not with the heap space, task stack space, or the same allocations to the timer task. I’m also reasonably sure the priority of the timer task is not an issue – I set it to 2 below the top priority and I have two other tasks running at 2 below that. Any help is appreciated. Ray

I will try and help, but don’t fully understand at what point it is going wrong.

The UDP timer task creation call hangs

Do you mean the software timer creation, rather than the timer task creation, because the time task is created by the scheduler, not FreeRTOS+UDP. What have you set the parameters listed on the following page to? http://www.freertos.org/Configuring-a-real-time-RTOS-application-to-use-software-timers.html Have you called FreeRTOS_IPInit()? If so, does the problem occur inside that function, or somewhere else, and if somewhere else, where? Regards.

I call FreeRTOS_IPInit from main before I call vTaskStartScheduler. The parameters for the timer task in FreeRTOSConfig.h are: /* Timers */

define configUSE_TIMERS 1

define configTIMERTASKPRIORITY ( 1 )

define configTIMERQUEUELENGTH 5

define configTIMERTASKSTACK_DEPTH ( 512 )

I’ve experimented with the timer task settings going with low/high priorities and large stack sizes/queue lengths. Nothing seemed to help. Other relevant settings are:

define configMINIMALSTACKSIZE ( ( unsigned portSHORT ) 512 )

define configTOTALHEAPSIZE ( ( size_t ) 131072 )

The call that is hanging is: xARPTimer = xTimerCreate( “ARPTimer”, ( ipARPTIMERPERIODMS / portTICKRATE_MS ), pdTRUE, ( void * ) eARPTimerEvent, vIPFunctionsTimerCallback ); inside prvIPTask. The puzzling thing is that the debugger can’t step into this call. I moved the call outside the task context and before the scheduler is called and it executes successfully. Once the scheduler is started, however, any call to a timer related function hangs in the same way: for example timer start, etc. I successfully downloaded the TCP/IP demo for SafeRTOS targeted for the RM48 and it runs fine on my RM46 – I verified the CLI and Ethernet interfaces including DHCP, ping and telnet functionality. I looked at the SafeRTOS HALCoGen project to compare the hardware configuration and I already had everything configured properly. Any help you can provide will be appreciated. I’m trying to get basic UDP capability working so I can prototype an application. If we go into production I plan to license SafeRTOS with the TCP/IP and CLI add-ons once we settle on a hardware platform as we need the advertised reliability. I suspect if we go into production we’ll end up with the RM57 for performance reasons. However, I’ve attempted to prototype on the RM57 and it is somewhat less mature (software wise) than the RM46. Ray

I found this code fragment in os_timer.c – it seems incorrect to me, byut maybe I’m missing something. It appears all tasks are suspended while the timer task is blocked waiting for the next time tick or a message…

        else
        {
            /* The tick count has not overflowed, and the next expire
            time has not been reached yet.  This task should therefore
            block to wait for the next expire time or a command to be
            received - whichever comes first.  The following line cannot
            be reached unless xNextExpireTime > xTimeNow, except in the
            case when the current timer list is empty. */
            vQueueWaitForMessageRestricted( xTimerQueue, ( xNextExpireTime - xTimeNow ) );

            if( xTaskResumeAll() == pdFALSE )
            {
                /* Yield to wait for either a command to arrive, or the
                block time to expire.  If a command arrived between the
                critical section being exited and this yield then the yield
                will not cause the task to block. */
                portYIELD_WITHIN_API();
            }

What am I missing? By the way this doesn’t have anything to do with my issue. Ray

I don’t know what os_timer.c is – this code comes from timers.c, so I presume it is the same file, just renamed. In the code snippet you posted, a task calling vQueueWaitForMessageRestricted() may place the task into the Blocked state, meaning a context switch is required so another task can be selected to run. It is possible for a context switch to be requested inside the xTaskResumeAll() function, but if it is not (if xTaskResumeAll() returns pdFALSE), then one is requested directly. Regards.

I commented out the call to FreeRTOS_IPInit and everything works. The timer task was created (no timers of course) and my other tasks are running. I’m going to try to create a timer in my application and see what happens. Ray

os_timer.c is, in fact, timers.c re-named. I previously compared the files using windiff and verified that. I guess TI felt the need to rename the file for their HALCoGen support. There are several other files done the same way, but I checked them all. Ray

OK, I created a simple timer in my application code and everything works as expected. I did not put a message on the timer queue before starting the scheduler – I believe the IP stack does that. Ray

It is perfectly ok to place messages on the timer queue before the scheduler is started, but be aware that nothing will read them from the queue until after the scheduler has started – so it is easy to fill the timer queue up. I would suggest the first thing to work out is why you can’t step into the functions – that seems very strange and may be the route cause of the issue. Regards.

I determined that the code hangs when the first task is started. The code hangs in os_portasm.asm at the instruction “cps #0x13”: ;/———————————————————–/ ; Start the first task by restoring its context.

    .def vPortStartFirstTask
    .asmfunc

vPortStartFirstTask cps #0x13 portRESTORE_CONTEXT .endasmfunc ;/*———————————————————–*/ I’m stumped for right now… Ray

I’m stumped too – but to what the code in your snippet is. I’m checking the code in the FreeRTOS download and vPortStartFirstTask looks like this in the asm file: ;/———————————————————–/ ; Start the first task by restoring its context.

 .def vPortStartFirstTask

vPortStartFirstTask: portRESTORE_CONTEXT Regards.

I’m attaching my assembly file (os_portasm.asm) for your review. I assume the file was generated by HALCoGen when I created the project.

I verified the os_portasm.asm file was generated by HALCoGen. When I imported the FreeRTOS+UDP source code, I included only those files not generated by HALCoGen. I’m using HALCoGen version v04.03.00. Do you think there might be an issue with using a newer version of HALCoGen? If so, what version do you recommend I use, and when do you think FreeRTOS+UDP will be ported to the newest version of HALCoGen? Thanks, Ray

When you generate the files – are you given any options as to the FreeRTOS version to use? I suspect your code is trying to use the MPU, and that might be the issue. Have you tried swapping the files out for the version included in the FreeRTOS download (which doesn’t use the MPU). Regards.

I’ve not looked in to either of those things. They are both good suggestions – I’ll investigate and get back to you with the results. Thank you for your help, Ray

I had to take a break and get away for awhile. In any event, HALCoGen does not allow a FreeRTOS version selection when generating code. It does, however, allow the MPU to be enabled/disabled. I disabled the MPU and re-generated code. Unfortunately, the code in os_portasm.asm did not change and the UDP initialization process fails in the same way. This validates me creating a timer in my custom code and it running fine. I’m back to trying to figure out why the timer in the UDP stack is failing. Have you not had any of your users attempt to do the same thing I’m trying to do? Also, do you know what is done differently in the SafeRTOS demo? Ray

Maybe I don’t understand what it is you are trying to do:

Unfortunately, the code in os_portasm.asm did not change

Interesting – I would have thought it would be different with and without the MPU.

Have you not had any of your users attempt to do the same thing I’m trying to do?

As far as I understand you are taking a working FreeRTOS project, then building the FreeRTOS+UDP code into the project and trying to initialise the FreeRTOS+UDP code using the published init API function. If so, that is how you are supposed to use FreeRTOS+UDP, and I’m not sure that anybody will have done anything different.

Also, do you know what is done differently in the SafeRTOS demo?

Is there a SafeRTOS demo that uses FreeRTOS+UDP? Regards.

OK. I couldn’t come up with a good reason as to why I couldn’t create the timer in the “prvIPTask”. So I started increasing the task stack size. Low and behold when the stack size reached 16384 the timer was created and the task is running. I’m not seeing the RM46x on the network yet, so it appears I have other issues which I’ll start working on. I increased the stack sizes by powers of 2 – it would not run at 8192, and it runs OK at 16384. I didn’t experiment further to determine where the break point is. I’m new to FreeRTOS but I know there is an API for getting more information from the OS. Right now I want to get the UDP interface working. I enabled ping so I can tell when the stack is working properly. Any tips you have will be appreciated. Ray

You should only need a small fraction of that stack size. Something very strange is going on. By increasing the stack to that size I suspect you are effectively blocking out a hole chunk of RAM that was being used by something else, but is now not used by anything (on the assumption the stack is allocated but most of the stack remains unused). http://www.freertos.org/Stacks-and-stack-overflow-checking.html http://www.freertos.org/uxTaskGetStackHighWaterMark.html Regards.

I jumped the gun – it wasn’t working at all. I too thought it was an outrageous amount of RAM allocated to the stacks. Maybe I need to start from the beginning. When I looked at the FreeRTOS-Plus distribution, I didn’t see a code composer studio project for the TI RM46x. I used TI’s HALCoGen and generated a project for the target. Then I took the files I found in <…FreeRTOSFreeRTOSV8.2.0FreeRTOS-PlusSourceFreeRTOS-Plus-UDP> and included them in my project. It appears most of the UDP demos are targeted for the Windows simulator. Am I going about this correctly? Ray

Yes – that is the approach I would have taken too. Assuming the port is known to be working, and malloc() is never failing, then I cannot think of any reason why doing that would cause an issue. Even if the software timer could not be created it should not crash or prevent you from stepping into the code. Something is fundamentally wrong somewhere – maybe you are ending up in a fault interrupt, or something like that. One thing you could do is try switching to assembly mode and try stepping into the function in assembly code to see what happens, or at least how far into the function you get before the debugger lets go. Which heap_x.c file is included in the project? (http://www.freertos.org/a00111.html) Regards.

I’m using Heap4.c per the recommendations and I’m using BufferAllocation2.c

After attempting to start the timer in prvIPTask and pausing the debugger, execution is always in the file sys_intvecs.asm at the prefetchEntry line: ;——————————————————————————- ; interrupt vectors resetEntry b cint00 undefEntry b undefEntry b vPortSWI prefetchEntry b prefetchEntry b _dabort b phantomInterrupt ldr pc,[pc,#-0x1b0] ldr pc,[pc,#-0x1b0] Does this provide any clues?

I set a breakpoint at the call to xTimerCreate in prvIPTask() and disassembled into assembly instructions. I see the following, and when I step through these instructions on the branch to xTimerCreate (EBFFD8F8 BL xTimerCreate) the processor jumps to sys_intvecs.asm as I described in the previous post. 0000c490: E59FCE44 LDR R12, $C$CON2 0000c494: E3021710 MOVW R1, #10000 0000c498: E3A02001 MOV R2, #1 0000c49c: E3A03002 MOV R3, #2 0000c4a0: E28F0FF7 ADD R0, PC, #988 0000c4a4: E58DC000 STR R12, [R13] 0000c4a8: EBFFDBF8 BL xTimerCreate You can see the parameters being loaded onto the stack: R12 has the timer name, R1 (10000) is the timer period, R2 (1) is autoreload, R3 (2) is eARPTimerEvent. I assume R0 is the address of the callback function. I’m not sure of the contents of R12.

Are you sure you are not using an MPU port? http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0363e/I31997.html Regards.

I am using an MPU port. I need to figure out how to turn it off in HALCoGen – a simple disable under the R4-MPU-PMU tab didn’t do it.

I guess I’ll have to contact TI as I can’t find a way to disable the MPU from HALCoGen. The HALCoGen GUI provides a tab for configuring the MPU and it appears as if it can be disabled, but the generated code doesn’t reflect disabling the MPU.

I spent a little time today reading up on the ARM MPU and how HALCoGen configures it. I consulted the TI RM46x TRM, the ARM TRM, and the FreeRTOS documentation on the subject. After all that, I OR’d portPRIVILEGEBIT with ipconfigUDPTASKPRIORITY in the source file FreeRTOSUDP_IP.c on line #127 where the “prvIPTask” is created. This allowed me to get past creating the timer in prvTask without a prefetch error. I still don’t have the network stack working correctly yet, but I’ve gotten past a significant issue. Can you think of any other issues I should be on the lookout for? Thanks for your help, Ray

Hi Ray – good call with the portPRIVILEGE_BIT, the stack has probably never been used with an MPU port before (very few FreeRTOS applications will use the MPU, whereas very few SafeRTOS applications will not use the MPU). I take it the code is no longer ending up in the abort handler, but still you have no communications. I would suggest the first thing to do would be to ensure the MAC driver is receiving network data. If you put a break point in the MAC driver’s interrupt, then send a ping to the board, does the interrupt ever execute? [sending a ping to an unknown IP address should generate an ARP message, which should be received by the hardware even if the IP address is not assigned to the hardware]. Regards.

I generated the port I’m using with HALCoGen v04.03.00. That version of HALCoGen uses FreeRTOS v8.2.0 – it doesn’t offer a choice about using the MPU. I’ve just started the debugging process to figure out why the stack isn’t working. One of the things I’m trying to track down is how FreeRTOS handles the IP and MAC addresses. It appears the MAC address is handled correctly but the IP address is reversed somewhere, but I’m not 100% positive about anything yet. I’m not sure the debugger allows breakpoints in an ISR, but I’ll figure out how to track data flow through the stack. I do have a question about the routine that I had to write: “xNetworkInterfaceInitialise”. It appears this routine can be called more than once – during initialization and whenever the network is determined to be “down”. I made sure the creation of “prvEMACDeferredInterruptHandlerTask” can only be called once, but initializing the hardware can be called more than once. After looking at the source code HALCoGen generates for the EMAC device driver, I call “EMACHWInit” every time “xNetworkInterfaceInitialise” is called. Is this the correct way to handle that? Ray

I’m not familiar with the code generated by HALCoGen, but if xNetworkInterfaceInitialise() is only called when the network is down it will be ok to call EMACHWInit() each time. Assuming EMACHWInit() initialises the DMA descriptors any packets already held in the descriptors would be lost of course. Also, if EMACHWInit() enables the MAC interrupt it would be a good idea to disable the interrupt manually before EMACHWInit() is called – if it does not do it itself inside the function. Regards.

I’ve got the UDP/IP stack running but I’m having problems. I have the stack configured to use DHCP for now. Using Wireshark I can see a DHCP Discover message go out from the RM46 and an offer comes back from the server. Next I see a DHCP Request go out from the RM46 and an ACK comes back from the server. After that I don’t see any more responses from the RM46. Eventually the RM46 stops and the debugger reports that the ARM had an exception again. I assume I probably need to review the settings in FreeRTOSUDPIP.h. Originally FREERTOSBIGENDIAN was defined to one and I was having very unstable behavior. I changed it to “0” and Set FREERTOSLITTLEENDIAN to one. That seemed to help, but the stack is still very unstable. Do you have a recommended set of settings for configuration compatible with the RM46/48? I want to use the UDP/IP stack in the simplest way – I just want to stream data on the network. When I’m not doing that I want the stack to not use unnecessary CPU cycles. Thanks, Ray

By the way, I’m not positive I’ve got the compiler settings correct for structure packing, etc. I’m using the TI v5.2.2 compiler. Ray

OK, I tweaked some of the stack and buffer configuration settings and I was able to get the RM46 to accept a DHCP IP address from the server. I enabled outgoing pings and was able to get the assigned IP address using Wireshark. When I ping the IP address from my host computer I got responses as expected. After that I did an “arp /a” from the host and verified the RM46 showed up with the right IP and Ethernet address. The RM46 runs a little longer after I tweaked the buffer and and stack configuration settings, but it still dies after just a few minutes. I assume this means I may have a memory leak somewhere (or a stack growth issue). I’m not using dynamic memory allocation to get data from the stack – I use statically allocated buffers and I verified I’m handling the indexing properly. Are you aware of anything in the stack that might be using memory if I didn’t configure it or set it up properly? If not, do you have any suggestions on how I can track down the leak (or stack growth) using TI’s CCS? I have no CLI or other way of seeing into the code. Thanks for your help, Ray

I would suggest first determining if it really is a memory leak by first defining a malloc failed hook, and then (if you are using one of heap1.c, heap2.c, heap4.c or heap5.c) periodically calling xPortGetFreeHeapSize() to see how much free space is available. Also, which memory allocator are you using? If you not using heap_4 then it might be an idea (as an experiment at least) to switch to it as it should prevent fragmentation of the heap as far as is viable. Regards.

OK. It tok me 12 days, but I finally have the FreeRTOS+UDP working on an RM46x HDK using the MPU. I did not implement a “zero copy” version, so it is not very efficient, but it works cooperatively with other tasks and meets my needs. The last issue I had was putting data on a queue at ISR level. I knew there was a special command to put data on a queue at ISR level, I just hadn’t gotten around to using it. The hooks for malloc and stack overflow were very useful in helping me troubleshoot. Thank you for all your help – I assume I’ll be back as I continue to use FreeRTOS. Ray

That’s great – I would appreciate you uploading the project to the FreeRTOS Interactive site http://interactive.freertos.org Regards.

Here is my project zipped up – according to my reading on http://interactive.freertos.org I’m supposed to post it on the forum. If I’ve violated a rule, please excuse me, I’m still new to the forum. Project Parameters:

1. Target – TI RM46L852ZWT Hercules microcontroller HDK,
2. Code generation – HALCoGen v0.4.03,
3. IDE – Code Composer Studio version 6.1.0.00104,
4. Compiler – TI v5.2.3

When I generated code with HALCoGen, I deleted their “osheap.c” file and replaced it with FreeRTOS+UDP “heap4.c” This is a simple implementation – it is not a zero copy implementation. I did not “tune” or otherwise optimize the task stack sizes or heap size. The purpose of the LED blinky tasks is to convince myself that I could run multiple tasks cooperating with each other while running the UDP/IP stack simultaneously The biggest issue I ran into was that I had to ‘OR’ in the “portPRIVILEGE_BIT” with the task priorities to get everything working correctly with the ARM MPU I hope you find this useful Ray

I forgot to mention that I used Wireshark to get the RM46’s IP address since it is configured to use DHCP. Ray