DAP and Tricore PFLASH programming

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
User18665
Level 3
Level 3
I try to download FW to Tricore TC397 chip using the DAP interface. I use FLASH programming commands like Load page, Write Burst, Erase Logical Sector and so on.
For example, 1Mbytes PFLASH programming time for me is about 15 seconds. But, MemTool do it in 5 seconds. That the reason for so big difference in programming time?. Are there any another ways for PFLASH programing, more faster, then DAP FLASH programming interface? As I understood, MemTool use DAP interface too.
May be MemTool use RAM programming monitor and it worka significantly faster?

Thanks a lot for any help.
0 Likes
23 Replies
NeMa_4793301
Level 6
Level 6
10 likes received 10 solutions authored 5 solutions authored
How many sectors are you specifying in Erase Logical Sector? It takes the same amount of time to erase 16K as 512K.

How fast is your tool driving the DAP clock? Going faster than 10 MHz can be dicey if you aren't using a shielded cable, or if your cable is too long.

Another possibility: is your tool configuring the AURIX clock system to run at the optimal speed? If you're not doing anything in particular, the system will be running off the internal 100 MHz oscillator, and the FSI (Flash Sequence Interpreter) will be running off a much slower clock than it could be.
0 Likes
User18665
Level 3
Level 3
UC_wrangler wrote:
How many sectors are you specifying in Erase Logical Sector? It takes the same amount of time to erase 16K as 512K.

How fast is your tool driving the DAP clock? Going faster than 10 MHz can be dicey if you aren't using a shielded cable, or if your cable is too long.

Another possibility: is your tool configuring the AURIX clock system to run at the optimal speed? If you're not doing anything in particular, the system will be running off the internal 100 MHz oscillator, and the FSI (Flash Sequence Interpreter) will be running off a much slower clock than it could be.



Thanks a lot!!!
1. Concerning the FLASH erasing - there isn't a problem, the erasing time quite the same like MemTool do it. The main problem is a programming time.
2. I clock DAP on 40MHz. It works quite stable: I can initialize, read and program the chip.
3. Concerning the AURIX clocking - it is a very good idea. Where I could read about the clock configuration?
0 Likes
cwunder
Employee
Employee
5 likes given 50 likes received 50 solutions authored
I would suggest that you download code to the PSPR of a core to control the Flash operations (adhere to the principle of locality). This would allow the fasted possible loading of the pages 64-bit (double word loads). In addition using burst mode for programming as this allows 256 bytes at a time. The DAP would then just concentrate on moving data to buffers that your PSPR program is using.

It is also faster if you have 5V available on the VEXT supply then you can change the HF_PCONTROL.PR5V

Concerning configuring the clock this is explained in the user's manual but there are also some application notes you could review along with looking at the start up files for any of the toolchains or bifaces.
0 Likes
User18665
Level 3
Level 3
cwunder wrote:
I would suggest that you download code to the PSPR of a core to control the Flash operations (adhere to the principle of locality). This would allow the fasted possible loading of the pages 64-bit (double word loads). In addition using burst mode for programming as this allows 256 bytes at a time. The DAP would then just concentrate on moving data to buffers that your PSPR program is using.

It is also faster if you have 5V available on the VEXT supply then you can change the HF_PCONTROL.PR5V

Concerning configuring the clock this is explained in the user's manual but there are also some application notes you could review along with looking at the start up files for any of the toolchains or bifaces.



Thanks!!

I suppose, that code, running from PSPR has to work faster. But I'm not sure, that I could be faster in 3 times. May be there are some tricks for programming, which is optimyze programming time also over DAP. I reached it for TC2xx family; so my programming time and MemTool programming time closely concide.
For TC3xx family situation is differ. MemTool programming 3 times less, then my. So, probably, I can decrease programming time for DAP, but I don't know how))))
0 Likes
NeMa_4793301
Level 6
Level 6
10 likes received 10 solutions authored 5 solutions authored
The critical thing is to make sure your FSI and FSI2 clocks are as fast as possible. The code execution time isn't nearly as important. Also make sure your wait states are correct after increasing any clocks.
0 Likes
User18665
Level 3
Level 3
UC_wrangler wrote:
The critical thing is to make sure your FSI and FSI2 clocks are as fast as possible. The code execution time isn't nearly as important. Also make sure your wait states are correct after increasing any clocks.


Thanks a lot for your reply. I have checked FSI and FSI2 clocks and it seems, that they set at maximum. From CCUCON0 register I saw, that only STM divider = 2, all other are set to 1;
0 Likes
NeMa_4793301
Level 6
Level 6
10 likes received 10 solutions authored 5 solutions authored
Hi Alexey. Can you also verify:

SYSPLLSTAT.LOCK=1 (PLL stable)
CCUCON0.CLKSEL=1 (fSOURCE0=fPLL0)

If not, you're running off the internal 100 MHz oscillator.
0 Likes
User18665
Level 3
Level 3
UC_wrangler wrote:
Hi Alexey. Can you also verify:

SYSPLLSTAT.LOCK=1 (PLL stable)
CCUCON0.CLKSEL=1 (fSOURCE0=fPLL0)

If not, you're running off the internal 100 MHz oscillator.



I have checked, and SYSPLLSTAT.LOCK = 0, CCUCON0.CLKSEL = 0 (fsource0 = fback).

It seems, that I need to change CCU settings. I tryed to do this (using the recomendadtion from User manual), but I always get bus error.
0 Likes
NeMa_4793301
Level 6
Level 6
10 likes received 10 solutions authored 5 solutions authored
Are you writing the registers through DAP, or from executing code? The registers are Safety ENDINIT protected, so a simple write will result in a bus error.

If you're writing them directly via DAP, consider disabling ENDINIT protection by setting CBS_OCNTRL to 0xC0.

Here's a small code example of setting an SCU Safety ENDINIT protected register, using the iLLD IfxScuWdt functions:
uint16  endinitSfty_pw;

endinitSfty_pw = IfxScuWdt_getSafetyWatchdogPassword();

/* Select fback (fosc-evr) as CCU input clock */
IfxScuWdt_clearSafetyEndinit(endinitSfty_pw);

while (SCU_CCUCON0.B.LCK != 0U)
{
/*Wait till ccucon0 lock is set */
/*No "timeout" required, because if it hangs, Safety Endinit will give a trap */
}

SCU_CCUCON0.B.CLKSEL = 0; /*Select the EVR as fOSC for the clock distribution */
SCU_CCUCON0.B.UP = 1; /*Update the ccucon0 register */
IfxScuWdt_setSafetyEndinit(endinitSfty_pw);
0 Likes
User18665
Level 3
Level 3
UC_wrangler wrote:
Are you writing the registers through DAP, or from executing code? The registers are Safety ENDINIT protected, so a simple write will result in a bus error.

If you're writing them directly via DAP, consider disabling ENDINIT protection by setting CBS_OCNTRL to 0xC0.

Here's a small code example of setting an SCU Safety ENDINIT protected register, using the iLLD IfxScuWdt functions:
uint16  endinitSfty_pw;

endinitSfty_pw = IfxScuWdt_getSafetyWatchdogPassword();

/* Select fback (fosc-evr) as CCU input clock */
IfxScuWdt_clearSafetyEndinit(endinitSfty_pw);

while (SCU_CCUCON0.B.LCK != 0U)
{
/*Wait till ccucon0 lock is set */
/*No "timeout" required, because if it hangs, Safety Endinit will give a trap */
}

SCU_CCUCON0.B.CLKSEL = 0; /*Select the EVR as fOSC for the clock distribution */
SCU_CCUCON0.B.UP = 1; /*Update the ccucon0 register */
IfxScuWdt_setSafetyEndinit(endinitSfty_pw);


I already tried to do in this way and result the same - bus error, while CCUCON0.LCK is clear (((
0 Likes
NeMa_4793301
Level 6
Level 6
10 likes received 10 solutions authored 5 solutions authored
OK then show us the code 🙂
0 Likes
User18665
Level 3
Level 3
UC_wrangler wrote:
OK then show us the code 🙂


There are a part of code. For debugging, I put real registers address:


//---------------------------------------------------------------------------------
ushort _pass = DAPgetSafetyWatchdogPassword();
//---------------------------------------------------------------------------------

DAPSetAddr(0xF000047C);
_bf[0] = DAPClientReadW();
DisplayL("OCNTRL", _bf[0]);
_bf[0] |= 0x00C0;
DAPClientWriteW(_bf[0]);

DAPclearSafetyEndinit( _pass );

do{
DAPClientReadBlock(&_bf[0], 1, 0xF0036030);
}
while(_bf[0] & (1<<31));

DisplayL("CCUCON0", _bf[0]);

_bf[0] &= ~(3<<28); // clear the CLKSEL bits
DAPClientWriteBlock(&_bf[0], 1, 0xF0036030); // !!!!!!!!!!!!!!!!!!!!!!!!!!!

_bf[0] |= 1<<30; // set UP bit to 1
DAPClientWriteBlock(&_bf[0], 1, 0xF0036030);

//DisplayL("Safety ENDINIT was set", 1);

DAPsetSafetyEndinit( _pass );

DAPClientReadBlock(&_bf[0], 1, 0xF0036130);
DisplayL("TRAPDIS_0 WR", _bf[0]);

DAPClientReadBlock(&_bf[0], 1, 0xF0036010);
DisplayL("OSCCON RD", _bf[0]);


The bus error appear during the first CCUCON0 writing attempt (marked //!!!!!!!!!!!!!!!!)
0 Likes
NeMa_4793301
Level 6
Level 6
10 likes received 10 solutions authored 5 solutions authored
Hi Alexey. Is the CPU stopped in this situation - i.e., has your tool issued a Halt After Reset Request?
Can you verify that CBS_OSTATE (0xF0000480) has ENIDIS set (bit 4)?
0 Likes
User18665
Level 3
Level 3
UC_wrangler wrote:
Hi Alexey. Is the CPU stopped in this situation - i.e., has your tool issued a Halt After Reset Request?
Can you verify that CBS_OSTATE (0xF0000480) has ENIDIS set (bit 4)?


I sent HARR to CPU before. And I saw, that CPU halted. But ENIDIS bit isn't set , when I perform Safety Endinit procedure. Probably, this is a reason, why I can't to write CCUCON0 register.
0 Likes
NeMa_4793301
Level 6
Level 6
10 likes received 10 solutions authored 5 solutions authored
alexeyPhyton wrote:
I sent HARR to CPU before. And I saw, that CPU halted. But ENIDIS bit isn't set , when I perform Safety Endinit procedure. Probably, this is a reason, why I can't to write CCUCON0 register.

Hmm... is there trouble in DAPClientWriteBlock? Can you write to unprotected RAM locations like, say, 0x70000000?
0 Likes
User18665
Level 3
Level 3
UC_wrangler wrote:
Hmm... is there trouble in DAPClientWriteBlock? Can you write to unprotected RAM locations like, say, 0x70000000?


Yes, I can read and write RAM from 0x70000000.
May be ClearSafetyEndinit doesn't work properly? I do it like I found it in iLLD driver.
0 Likes
NeMa_4793301
Level 6
Level 6
10 likes received 10 solutions authored 5 solutions authored
Can you list the exact sequence of register writes that your ClearSafetyEndinit is doing?
0 Likes
User18665
Level 3
Level 3
UC_wrangler wrote:
Can you list the exact sequence of register writes that your ClearSafetyEndinit is doing?



Below, the Clear Safety Endinit procedure:


void DAPclearSafetyEndinit( uint16 password )
{
uint32 _con0, _rel, _tmp32;

DAPClientReadBlock( &_con0, 1, SCU_WDTSCON0_REG);
_rel = _con0 & 0xFFFF0000;

if (_con0 & SCU_WDT_LCK)
{
/* see Table 1 (Password Access Bit Pattern Requirements) */
_con0 = (1 << SCU_WDTSCON0_ENDINIT_OFF) |
(0 << SCU_WDTSCON0_LCK_OFF) |
(password << SCU_WDTSCON0_PW_OFF) | _rel;
DAPClientWriteBlock( &_con0, 1, SCU_WDTSCON0_REG);
}

/* Clear ENDINT and set LCK bit in Config_0 register */
_con0 = ( 0 << SCU_WDTSCON0_ENDINIT_OFF) |
(1 << SCU_WDTSCON0_LCK_OFF) |
(password << SCU_WDTSCON0_PW_OFF) | _rel;
DAPClientWriteBlock( &_con0, 1, SCU_WDTSCON0_REG);

/* read back ENDINIT and wait until it has been cleared */

do
{
DAPClientReadBlock( &_con0, 1, SCU_WDTSCON0_REG);
}
while ((_con0 & SCU_WDT_ENDINIT ));
}
0 Likes
NeMa_4793301
Level 6
Level 6
10 likes received 10 solutions authored 5 solutions authored
That looks like a faithful translation of the iLLD's Ifx_Ssw_clearSafetyEndinitInline() to me.

Can you read back the value of SCU_WDTSSR after each write to SCU_WDTSCON0?
0 Likes
User18665
Level 3
Level 3
UC_wrangler wrote:
That looks like a faithful translation of the iLLD's Ifx_Ssw_clearSafetyEndinitInline() to me.

Can you read back the value of SCU_WDTSSR after each write to SCU_WDTSCON0?



Yes, I can read SCU_WDTSCON0 register. At start its locked (LCK bit set to 1). Then it became unlocked. After the last writing it came locked again.
0 Likes
NeMa_4793301
Level 6
Level 6
10 likes received 10 solutions authored 5 solutions authored
alexeyPhyton wrote:
Yes, I can read SCU_WDTSCON0 register. At start its locked (LCK bit set to 1). Then it became unlocked. After the last writing it came locked again.

Well yes, but can you also please read the SCU_WDTSSR register 🙂
0 Likes
User18665
Level 3
Level 3
UC_wrangler wrote:
Well yes, but can you also please read the SCU_WDTSSR register 🙂



Yes, The SCU_WDTSSR value before and after ClearSafetyEndinit is the same: 0xFFFC0010 (TO bit is set).
0 Likes
User18665
Level 3
Level 3
UC_wrangler wrote:
Well yes, but can you also please read the SCU_WDTSSR register 🙂


Sorry, I read your prev. message inattentively . I checked SCU_WDTSSR value after the each write to SCU_WDTSCON0 and it is constant and = 0xFFFC0010.
0 Likes