• State
  • Locked Locked
  • Replies 7 replies
  • Subscribers 99 subscribers
  • Views 1991 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

RTOS/OMAP-L138: Timestamp module behavior at stand alone

UNA
Mastermind 7980 points
Part Number: OMAP-L138
Other Parts Discussed in Thread: SYSBIOS, TMDSLCDK138

Tool/software: TI-RTOS

Hi,

I want to know how to use 'ti.sysbios.family.arm.da830.TimestampProvider' module.
I am verifying programs for the ARM9 core using TMDSLCDK138.
It is operating normally during debugging using CCS. but, this Timestamp module of SYS/BIOS does not work when NAND booting with the same program.
If it connects to CCS after NAND boot and runs, then the timestamp module appears to work.

Evaluation environment:
* CCS : CCSv7.0.0.00043
* H/W : TMDSLCDK138
* SYS/BIOS : v6.46.4.53
* XDC tool : v3.32.1.22_core
* AISgen : v1.13(D800K008)
* Flash and Boot Utilis : v2.40

I will attach a project to make it reproduce. It is a program to toggle LED 5(D5) on LCDK periodically using the timestamp module.
Test_LCDK.zip

Does someone know how to make it work stand-alone for the Timestamp Provider module?

Best regards,
H.U

  • 0
    TI__Guru* 96960 points
    I expect something in the gel file is doing some initialization that is changing the behavior. Comment out things in the OnTargetConnect to figure out if that is the case?

    Todd
  • 0 in reply to ToddMullanix
    Mastermind 7980 points
    Hi Todd,

    Thank you for your reply.
    I have investigated the effect of GEL by comment out some functions , it did not depend on the setting of the GEL file.

    Could you check the program I attached in the previous post?
    You will be able to confirm that LED5 is turning on/off , if it is connected to CCS without GEL file and run after NAND boot .
    Does this module have to be used with CCS(JTAG)?

    Best regards,
    H.U
  • 0 in reply to UNA
    TI__Guru* 96960 points
    Can you confirm that taskFxn2 is running?

    Also, prevTime is un-initialized in taskFxn. This should have given a compiler warning? Can you resolve this (and any other compiler warnings) and re-try the test case.

    Todd
  • 0 in reply to ToddMullanix
    Mastermind 7980 points

    Hi Todd,

    Yes, taskFxn2 is running normally even in the standalone(NAND boot). 

    I have modified the code to initialize prevTime, however, the problem was not solved.
    It seems that ICE-Crusher is used for "'ti.sysbios.family.arm.da830.TimestampProvider' module.",  I think that it depends on usage of H / W.

    Could  you reproduce this problem on your LCDK?

    Best regards,
    H.U

  • 0 in reply to UNA
    TI__Guru* 96960 points
    Someone is looking into this.
  • 0
    TI__Mastermind 21645 points

    Hi H.U,

    The taskFxn has a bug. "prevTime" is used first time without being initialized. Depending on what initial value it picks up from the stack, it may increase the initial LED toggle period by a noticeable amount of time. When you boot from NAND, maybe the stack usage changes and the "prevTimer" initial value causes the toggle period to increase to a very high number.

    Screenshot:

    Best,

    Ashish

  • 0 in reply to Ashish Kapania
    Mastermind 7980 points

    Hi Ashish,

    I changed the program  to initialize "prevTime", but the result did not change. The cause of this problem does not depend on the initialization of "prevTime".
    Could you reproduce the phenomenon with EVM?

    Best regards,
    H.U