Have someone used Trace Hook Macros? or where can i find the demo of using Trace Hook Macros? Thanks.
What do you want to achieve with them? Maybe we can help here.
I just port to MSP430F5438+IAR 4.2, so i need to confirm if my port is correct. I see the FreeRTOS web site for information, but i can’t find any examle for these macros. Maybe you can give me some advices. thanks.
The macros are very generic and can be used in lots of different ways. If you say what you actually want to do (see how much idle time there is, how often a task runs, the order in which tasks run) and how you want to view the information (digital output, analog output, buffer) then we might be able to help here.
Does your port run in the debugger?
I just port to MSP430F5430 + IAR 4.2, both in debugger and release. and I create two task which flash two LEDs with different fixed frequency. It seem run fine. But I don’t confirn the kernel is running well. So I plan use trace macro to see the status of kernel. The manual on the web is too simpleness, I can’t implement my trace, I need help.
Sounds like you need to spend more time in the debugger - no reason to make release builds if you don’t know that your debug version is working or not.
Set breakpoints in your TIMER IRQ and see if that is working.
Get a scope, program some I/O’s and create a couple of tasks that toggle the I/O’s - or even toggle the I/O’s in your timer IRQ.
I already create three tasks in my test main(), each one flash one LED at different frequency using Taskdelayuntil() function, and it work ok. But I really need to know if the kernel mechanism such as switchcontext work correct. so I think I can use trace macro to confirm. But I do know how to use them. Thank you for faster replay.
Move one of your tasks to be > 0x10000 (above 64K) - this will check if your port is OK running in 430X mode. You define this in your linker command file. Maybe you don’t want to run in 430X mode initially until you get your port stable.
Put a taskYield() in your LED tasks forcing them to do a context switch.
Put a breakpoint range on 0xFFFE-0xFFFF to make sure the board isn’t constantly resetting - I’ve seen small projects do this when they are unstable - and it isn’t always apparent.
Check values in tasks.c like xTickCount and uxCurrentNumberOfTasks - xTickCount should increment until it rolls and uxCurrentNumberOfTasks should reflect the # of tasks that are running.
If you do the above you will prove the kernel is correct. This way you don’t have to worry about trace hook macros. I think when you have the system stable and you want to do some fine tuning - the the trace hook macros may be more appropriate.