RTOS/AM3352: Inaccurate results from timestamping

The RTOS team have been notified. They will respond here.

bump

Cobsonchael,
Need to look into this and get back to you.

Lali

Cobsonchael,

Would you be able to take the GPIO out of the picture since its for debugging and use another mechanism to check the timing?
Trying to take the GPIO out of the picture.

Lali

i'd be willing to try things, sure. but i ask you, with timestamp itself in question, and no gpio to verify the routine execution, what do i use as a metric to measure an accurate 1us wait time?

cobsonchael,
Will need to take a look at this and get back to you.

Lali

my input clock is 19.2MHz.

my core divider is N = 38 (19.2MHz/39) and my M=2031

this puts my core freq at:

CLKOUT = 999876923Hz and

CLKOUTX2 = 1999753846Hz

so from what i understand my BIOS CLK freq should be 999876923. before i was using what was in my platform file which was 999.8MHz

with the new frequency i am able to get a pretty reliable timestamp duration, however it is only after i set my CPU frequency to 499938461 (1/2 the expected core frequency). what setting do i have that gives me 1/2 core speed?

I'm not sure of the semantics in the BIOS, but certainly the ARM core runs off of a different PLL than the DMtimer.
The MPU subsystem (which contains the ARM Cortex-A8) runs off the MPU PLL (see figure 8-12 in the TRM). This is what you are changing when moving between 1GHz and 600MHz. The output of this PLL doesn't go anywhere else, so it should affect the operation of any other peripheral
The DMTimers have several possible clock sources (see the integration section of the DMTImer_1ms chapter). The options are the HF clock (in your case, 19.2MHz) or other 32K clock sources. If you choose CLK_32KHz, this comes from the PER PLL, so if the PLL is set at shown previously in the spreadsheet, then this should be 32KHz. Similarly, the other 32K sources are from external or on-chip, so those should not change as well.

Regards,
James

i'm not changing PLLs to go from 1GHz to 600MHz, all i am changing is the text in the sysbios field "CPU clock frequency" which i would assume would be 1GHz, not 600MHz, but the only way i can get an accurate result from the timestamp is to enter 600MHz. this field is only important because it is what is returned when you request the CPU freq in the timestamp module.  this does not change any clocking on the device. i am very much aware of this. what i am not aware of is why, when it should be 1GHz, i do not get accurate results when i use 1GHz, and i do when i use 600MHz?

in addition i am not concerned with the DMTimer and how it pertains the timestamp. i know the 2 have very little to do with one another. the other post is a separate problem that does not apply here. i linked to it merely to show where i got my new PLL settings from.

OK, I misunderstood.  I'm answering mainly from the way the device works, I don't have a lot of knowledge on how SYSBIOS is implemented.  I'll let that team chime in here.

BTW, slight typo in what i said above:  The output of this PLL doesn't go anywhere else, so it should not affect the operation of any other peripheral

Regards,

James

so i think you posted this in the wrong topic. this is about timestamp, not the timer mismatch error

Please note that ARM cores don`t have TSCH And TSCL register. This is derived using Systicks which have dependency on CPU clock and can be directed to use Timer clock. I have looped in TI RTOS experts to comment on defaults for AM3359 platform.

Regards,
Rahul

Hi cobsonchael,

BIOS uses the cycle count for the AM335X platforms Timestamp, so it should be running at the CPU frequency.  Did you set BIOS.cpuFreq.lo in your .cfg file to match the value of the CPU frequency you changed to?  If those don't match, your timestamp numbers will be off.

Best regards,

Janet

if you follow the thread janet you would read that i did set it to the correct CPU freq and it is off. i posted my settings and what i expected my frequency to be (1GHz) and nobody has said i am wrong. so when i put my expected frequency (1GHz) i get inaccurate results. when i put a frequency that isn't what i expect (600MHz) i get accurate results.

I think there is a mismatch in the CPU frequency you're actually running at, and what BIOS thinks the CPU frequency is. If you are changing BIOS.cpuFreq in your .cfg file to 1GHz and the timestamps are inaccurate, then my first guess would be that your CPU frequency is not really 1GHz. If setting BIOS.cpuFreq to 600MHz gives you accurate timestamps, it sounds like your CPU frequency is really 600MHz, and is not getting changed. Can you try verifying that your CPU frequency is approximately what you expect it to be (e.g., by running a loop of code that should take a known amount of time)?
Best regards,
Janet

yes, there is a mismatch. this is why i am posting. the loop of code that takes a certain amount of time is the code i posted in my original comment. i posted my M and N values for the core and it still isn't right. i want to know what is going on and i am not knowledgeable enough in the part to know why it's behaving this way. PLEASE read the post and the replies so you can get caught up on what was already said. if you need a new question to focus on then how about:

How is it that i can set my divider values for 1GHz core operation and not get accurate timestamps unless i set the SYSBIOS CPU freq to 600MHz? is there some significance to 600MHz?

Hi cobsonchael,

Sorry for not being more clear in my previous post.  I had meant that you use a loop of code that is independent of Timestamp, for example, just a for () loop that runs for a large number of iterations.  It should run for a number of seconds large enough so that you can measure the time spent with the second hand of a watch.  You can run the loop in your program where you have not changed M and N and get an approximate measure of the time taken. Then you can change your M and N values to what you think would cause the processor to run at 1GHz..  Measure the time taken by the loop.  If your CPU frequency is really changing, then I would expect the loop to take less time.  This is a very rough measurement, but would at least give us an idea of whether or not your code to change the CPU frequency (in a GEL file?) is working.

Best regards,

Janet

i have made changes to my M and N values and the timestamp routine i originally posted was different before and after. i do know the core freq is changing when i do that.

so it looks like my issue was with my OPP voltage (and lack of understanding on this topic) on VDD_MPU in combination with the right values for core M and N. i am running at 1GHz now

I'm glad to hear you are now running at 1GHz. Hopefully the timestamps are now accurate.
Best regards,
Janet