TDA4VM: How to evaluate RBL execution time for TDA4VM

Hi, 

j721e is excluded because there is no timer setup by RBL for this calculation. Let me check internally if there is any alternate method we can use for this.

Regards, 
Parth. 

Thank you. Looking forward to your further reply.

Best Regards

OK, I'll have a try with the GPIO. Thanks.

By the way, do you have any information concerning the reasonable range of RBL execution time?

Best Regards.

Mian

Hi,

I tried to do the measurement with a GPIO, but the result turned out to be beyond my expectation.

I pulled up a GPIO in SBL and noted the timestamp with R5F counter. The code and the actual prints during boot are shown in snapshots below.

From the log, the GPIO was pulled at about 161ms since R5F boot.

Meanwhile, I measured the time between VDD_CPU_AWS which I suppose is the power-on time of the SOC and GPIO-up with an oscilloscope. The result is about 216ms as shown in picture below.

I suppose the difference between these 2 numbers relates to the initialization time before SBL. That is about 216 - 161 = 55ms.

The number is much bigger than I would expected and also differs from that of J721s2.

I wonder whether I'm doing the right meseasurement? If so, what are the possible reasons for such significant difference from J721S2?

Best Regards.

Mian

Hi Mian,

Re-routing this thread to another engineer. Please expect a delay in response till Monday as he is out of office.

Regards,
Parth

Hi, 

Could you please confirm if you are following the below step to enable the GPIO and measure?

(+) [FAQ] TDA4VM: How to identify a GPIO and toggle the same - Processors forum - Processors - TI E2E support forums

The above is for J721E, but you could identity a GPIO with Test point and follow the same procedure.

Regards,

Nikhil

HI,

I'm not following the exact steps as shown in the link. As I understand that's done by directly manipulating the registers.

Instead, I'm using the interfaces provided by PDK for pinmux and GPIO pulling. I suppose the results are the same.

Besides, the GPIO voltage level stays low if I don't apply my test code so I think it works.

Best Regards,

Mian

Hi Mian,

Are you using SDK 9.1?

Mian DENG said:

From the log, the GPIO was pulled at about 161ms since R5F boot.

Is this GTC timer? if yes, I believe in the SDK 9.1, the GTC timer is started at a later stage i.e. after DDR init, TIFS init. etc... Could you try moving this up to the start of SBL main and then check the difference? 

Or have you already done that?

Regards,

Nikhil

Hi Nikhil,

Yes I'm using SDK9.1, but I'm not using GTC timer for time profiling.

Instead I'm using a local counter of MCU-R5F, which is also used by SBL boot time profiling and is accessable in the beginning of SBL as shown in snapshot below. 

So I suppose it doesn't matter where I add the profiling code. In fact I add the test code at a relatively late stage on purpose to ensure the pinmux and GPIO interfaces are available.

Best Regards,

Mian

Hi Mian,

The value returned by SBL_ADD_PROFILE_POINT is the clock cycles and is not in microsecond. This should be divided by the clk_freq to get it in micro seconds

Please refer the API SBL_printProfileLog() for the same.

Mian DENG said:

That is about 216 - 161 = 55ms.

Also, I do not understand your way of calculation. The time taken from ROM to load SBL could be taken directly from the oscilloscope by toggling the GPIO to low and the beginning of the SBL main(). Not sure why the difference is needed here.

In the FAQ, the GPIO is initially high upon PowerON and is pulled down at the beginning of main to measure the time. 

Regards,

Nikhil 

Hi Nikhil,

Yes I noticed that the value returned by SBL_ADD_PROFILE_POINT is the clock cycles and is not in microsecond, so I did divide it by clock frequnecy as done by the API SBL_printProfileLog as shown below.

The frequency is 1G Hz, so I divided it by 1000 to get a value in microsecond.

To explain my way of calculation, I'd like to explain a bit about my way of evaluation first.

I'm using a GPIO which is initially low upon PowerON and I pull it up in SBL main. Since I do not pull up the GPIO at the very beginning of SBL, which I think is actually quite hard to achive, I get 3 time points during the test as shown below.

From the oscilloscope I can get the time taken between PowerON and GPIO pull-up, which is T3 - T1 = 216ms.

From the log print of SBL I can get the time taken from SBL start to GPIO pull-up, which is T3 - T2 = 161ms.

So the time before SBL start is T2 - T1 = (T3 - T1)  - (T3 - T2) = 216 - 161 = 55ms.

Best Regards.

Mian

Hi,

Mian DENG said:

The frequency is 1G Hz, so I divided it by 1000 to get a value in microsecond.

Sorry, I missed that part. Then the counter value is correct.

May I know in which boot mode are you seeing 55ms of RBL time?

Mian DENG said:

Instead, I'm using the interfaces provided by PDK for pinmux and GPIO pulling. I suppose the results are the same.

I think, the direct registers would be faster when compared to the APIs. Hence, I would suggest you try toggling the register and toggle the GPIO at the beginning of the SBL main.

Regards,

Nikhil

Hi,

I'm using OSPI boot mode and the model of NorFlash I'm using is MT35XU512ABA1G12, which is the same as TI EVM board.

I would try direct register way later.

Best Regards.

Mian

Hi

I did the test once again by toogling the GPIO at the very beginning of SBL main via direct registers. The result is still 54ms. You may find test code and result below.

The value is still beyond expectation.

Could you please do a test, too?

Best Regards.

Mian

Hi Mian,

Sure, I shall do a test at my end on TDA4VM in OSPI boot mode by toggling the GPIO. I shall get back to you by Monday with the results.

Regards,

Nikhil

Hi Mian,

I tried this on the TP45 (WKUP_GPIO_6) on j721e, where I toggled the GPIO to high at the beginning of the SBL main.

I got around 41msec for SBL binary size (around 338KB).

As attached below, the yellow line represents the MCU_PORZ_OUT. It takes around 16ms to release the same after power ON. Hence the effective time for ROM init + SBL load is 41 - 16 = 25 msec

Could you let me know what is the size of your binary? 

Regards,

Nikhil

Hi Nikhil,

The size of my SBL binary is about 332KB. So I guess the size is not the problem.

Maybe there's some difference between our ways of evaluation?

What do you use as symbol of power-on? I'm using VDD_CPU_AVS. And what does MCU_PORZ_OUT signify?

Besides, are 41ms or 25ms as expeted?

Best Regards,

Mian

Hi Mian,

A bit more clarity now.

From the above pins,

MCU_RESETSTATz to SBL_main() start is around 8 msec for J721s2 (xSPI boot mode) (Same as the values in the datasheet from the DM timer)

MCU_RESETSTATz to SBL_main() start is around 18 msec for J721e (OSPI boot mode)

MCU_RESETSTATz would be high when MCU R5 is out of reset by the DMSC ROM.

The timing before that (i.e. from VDD AVS to MCU_RESETSTATz ) is 22msec for J721e.

This is the timings that are expected.

Regards,

Nikhil

Hi Nikhil,

From the picture you attached, may I consider MCU_PORz_OUT (B28) as a symbol of power-on and MCU_RESETSTATz (C27) as a symbol of MCU_R5F starting running? 

The expected time before SBL main consists of 2 parts. The first is from power-on to DMSC releasing MCU_R5F which is about 22ms. The second is from MCU_R5F release to SBL main starting which is about 18ms. And the time in total is about 22 + 18 = 40ms.  Is this understaing correct?

If so, I suppose your result (41ms) is more close to expections than mine (54ms). Do you have any advice on from where the difference might come?

Best Regards,

Mian

Hi Mian,

Mian DENG said:

The first is from power-on to DMSC releasing MCU_R5F which is about 22ms

There is a small correction here. After the MCU_RESETSTATz starts the ROM code. (i.e. DMSC and then MCU_R5). So typically, 18 msec is the start of ROM till SBL and the rest are the hardware related timing before this.

Mian DENG said:

If so, I suppose your result (41ms) is more close to expections than mine (54ms). Do you have any advice on from where the difference might come?

Are you also measuring on the EVM? or is this your custom board?

Regards,

Nikhil

Hi Nikhil,

I'm doing the test on our custom board. 

And I did some further measurements today. 

The time between MCU_PORz_OUT and MCU_RESETSTATz on my bnorad is about 26ms, which is not far from 22ms. The reseult is attached below.

The time between MCU_RESETSTATz and GPIO pull-up, i.e. SBL main is about 18ms, which matches your statistics. 

If I add up the result of these 2 parts, I get 26 + 18 = 44ms，which is quite close to your result.

But, here comes the different part, I also measured the time between VDD_CPU_AVS and MCU_PORz_OUT and the result is about 10ms.

If I add all these 3 parts up, I get 54ms, which is exactly my test result earlier.

So now I suppose the difference between your test result and mine is due to the time between VDD_CPU_AVS and MCU_PORz_OUT.

Do you think 10ms is a reasonable value? And how long is this duration on your board?

Best Regards,

Mian

Hi Mian,

Mian DENG said:

The time between MCU_PORz_OUT and MCU_RESETSTATz on my bnorad is about 26ms, which is not far from 22ms

In my case, PowerON to MCU_PORz_OUT -> 16msec

                   MCU_PORz_OUT to MCU_RESETSTATz -> 7 msec

                   MCU_RESETSTATz to SBL main -> 18msec

I think in your case, MCU_PORz_OUT to MCU_RESETSTATz is taking more time than EVM. Please check the schematics and the power up sequence of the board to check what is happening here. 

Regards,

Nikhil

Hi Nikhil,

Could you please explain a bit what does the SOC do from power-on to  MCU_PORz_OUT and from MCU_PORz_OUT to MCU_RESETSTATz? 

Or where can I find such information?

Thank you.

Regards,

Mian

Hi Mian,

This is more of a HW related question, and I would involve the HW experts here to answer this. But the main thing that happens between MCU_PORz_OUT to MCU_RESETSTATz is POST (i.e. BISTs)

When I bypassed the BIST at my end, the time came down from 7 ms to 0.5 ms.

Regards,

Nikhil

MCU_PORz_OUT is just a buffered version of MCU_PORz (input to IC) - thus time should be to propagate through the internal logic.

MCU_RESETSTATz is the internal reset status.  Thus time between MCU_PORz_OUT and MCU_RESETSTATz is the device releasing from reset, running any internal test/diagnostics (i.e. BISTs), and ROM starting to execute.

Does that mean the time between MCU_PORz_OUT and MCU_RESETSTATz basicilly depends on the logic of the SOC?

Best Regards,

Mian

Yes - and as previously mentioned, may include things like BISTs if enabled.

Since the time mainly depends on the logic of SOC, what do you think might be the reasons for such significant difference between my test result and that of Nikhil's?

Best Regards,

Mian

The POST selection has already been discussed.  That could be a difference.  Are the types of devices that same between the compared timing (both GP or both HS-FS, etc)?  I don't know if difference security check affect the release of RESETSTATz.   It could also be the power up sequence/stability of the input clock are delaying internal reset.  Have you verified all power supplies are stable prior to MCU_PORz release and also that clock input is stable prior to MCU_PORz release?