OVC TC364 First read after overlay switch gets data from non overlay memory, why ?

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

cross mob
User21958
Level 1
Level 1
10 sign-ins 5 likes given 5 replies posted

Hello, 

I am using TC364 and getting OVC working for CAL data page overlay. Just using CPU0 at present

I configure a single OVC block to overlay PFLASH from Sector 8 with LMU RAM from Sector 9. 
Before the switch I write some data into the overlay RAM for a test. Then I switch on the overlay. RABRx.OVEN is clear but all other fields in RABRx OMASKx and OTARx are setup. OVCENABLE is already enabled for CPU0. OSEL.SHOVEN is set - ready to enable the OVC block. Then I write to OVCCON to switch on OVC. 
Then repeat reads from the PFLASH addresses and LMU RAM addresses.

The first read from PFLASH address range gets the value left in PFLASH. The second read and all further reads from PFLASH address range gets the value from LMU RAM as expected. 

I have tried using cached and non cached address ranges (0x8000 0000 or 0xA000 0000 for PFLASH and 0x9000 0000 or 0xB000 0000 for LMU RAM). I get the same result in both cases. 

If I add 2 dsyncs after the write to OVCCON to switch I get the expected data on the first read after the switch (value from RAM not PFLASH). Sometimes 1 dsync is enough, but not always !

Can anyone help me understand why the first data read is getting the value from PFLASH not the overlaid LMU RAM please.

Also for calibration data pages is it generally better to avoid cached areas ? 

I will try to read into Tricore cache coherency and have looked at other OVC related posts. 

Many thanks

0 Likes
6 Replies
µC_Wrangler
Employee
Employee
50 solutions authored 100 sign-ins 25 likes received

Are you clearing the cache via OVCCON.DCINVAL=1 when switching?

0 Likes

hi µC_Wrangler. 

Yes I did set OVCCON.DCINVAL = 1 when switching. 

Thanks for your reply, pls let me know if you need further info from me. 

0 Likes
µC_Wrangler
Employee
Employee
50 solutions authored 100 sign-ins 25 likes received

Can you share a code snippet?  When you're writing DCINVAL, is CSEL0 set in the same write?

0 Likes

Hi µC_Wrangler, 

pls see snip below. 
I do the same for switch off the overlay but set OVSTP bit instead of OVSTRT bit. 

For the CSEL bit(s) I access via the .U union member because I could OR in 0X03UL to set both CPUs CSEL bits. 

I find adding 2 DSYNC() after the write to SCU_OVCCON.U seems to allow reading the correct value after the switch. For the test I am reading as soon as I can after the switch operation. 

 

 

/* Create a local copy of the OVCCON reg struct type so we can setup the wanted bit fields before the single write */
Ifx_SCU_OVCCON locOVCCON;
locOVCCON.U = 0UL;

/* set OVSTRT for starting the OVC blocks based on setting in OSELn */
/* set DCINVAL for invalidate cache and force re-reading from memory */
locOVCCON.B.OVSTRT = 1;
locOVCCON.B.DCINVAL = 1;
/* set CSELn bits for CPU(s)n switch */
locOVCCON.U |= 0x01UL;

/* Disable all ints */
DISABLE();

/* should do the DSYNC before the switch */
DSYNC();

/* write to the real register from local copy to perform page switch */
SCU_OVCCON.U = locOVCCON.U;

/* enable interrupts again */
ENABLE();

0 Likes
MoD
Employee
Employee
50 likes received 500 replies posted 100 solutions authored

The problem comes from the Store Buffers (see also UM V2.0 part 1 chapter 5.3.4.3). Under some cicrcumstances there is a priorisation of load instruction over store instruction especially if the read comes from SRI and the write goes to SPB (as in this situation).  

Readback the SCU_OVCCON register or any other SPB register. This make sure that the read on SRI will not prioritise.

User21958
Level 1
Level 1
10 sign-ins 5 likes given 5 replies posted

Hello MoD, 

thank you very much for you help. I added a readback from SCU_OVCCON as you suggested and this seems to have fixed. I read though chap 5.3.4.3, thank you for directing me there. 

In my previous tests I tried adding a DSYNC() after the write to SCU_OVCCON. This improved things a little (just the first read from the overlay area was wrong. Then I tried adding a second DSYNC() and this seemed to fix both the reads from overlay area, but I don' t know why and I felt sure it was not the right way to resolve so I came here to ask.

Even after reading 5.3.4.3 I am still a little confused here. On one hand it says the DSYNC can flush the store buffer to ensure data is written (stored) to local memory before execution of next instruction. So I imagined it would force the write to SCU_OVCCON before any further reads (loads) from any address. 

If you can explain to me why the DSYNC after write/store to SCU_OVCCON is not the right approach I would be very grateful. 

Thank you very much to both MoD and µC_Wrangler

0 Likes