Trace Hook Macros

Kernel
1

zy015240 wrote on Thursday, July 09, 2009:

Hi all,
    Have someone used Trace Hook Macros? or where can i find the demo of using Trace Hook Macros? Thanks.

2

davedoors wrote on Thursday, July 09, 2009:

What do you want to achieve with them? Maybe we can help here.

3

zy015240 wrote on Thursday, July 09, 2009:

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.

4

davedoors wrote on Thursday, July 09, 2009:

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.

5

jwestmoreland wrote on Thursday, July 09, 2009:

Zy,

Does your port run in the debugger?

Regards,
John

6

zy015240 wrote on Friday, July 10, 2009:

Hi John,
    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.

Regards,

ZouYong

7

jwestmoreland wrote on Friday, July 10, 2009:

ZouYong,

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.

HTH,
John

8

zy015240 wrote on Friday, July 10, 2009:

Hi John,
   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.

9

jwestmoreland wrote on Friday, July 10, 2009:

ZouYong,

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.

10

zy015240 wrote on Friday, July 10, 2009:

Hi John,
    Thanks for you advice. I will do follow your advice next week. BTW, I download your IAR+MSP430F5438 port from your web site and send you email for unzip password. After I test what you say ,I will let you know. Thanks.