Inconsistency between RM0403 flash registers description and SPC582B50

Yannek · ‎2020-05-24

Hi,

One question at the beginning: how to clear interrupt flag in SPC582B50 for "Flash controller Prog/Erase/Suspend IRQ" (vector 185)? I can't see any related interrupt flag in the manual, MCR.DONE also cannot be cleared manually.

Once IRQ related to flash erase is issued, the IRQ_Handler is called over and over until I disable the interrupt at all (MCR.PECIE = 0).

-----

I found some incosistencies between Reference Manual RM0403 and actual behaviour of SPC582B50 flash registers.

According to RM section 32.3.2.3 to 6 - all LOCKx registers should be set to all-1s after reset.

I observe otherwise:

The same sections of RM say:

"The LOCK field is not writable:

– Once an Interlock Write is completed until MCR.DONE is set."

I observe, that write to LOCKx registers (restoring the lock) is not possible right after MCR.DONE is set. I also need to clear MCR.EHV, then I can write to LOCKx registers.

Can you please confirm which one is correct?

Best,

Yannek

Yannek · ‎2020-05-29

I also found that SEL0 register of FLASH_0 module is not initiated to all zeros (as stated in RM0403), but one of bits is set. This happens only after programming UC by JTAG/UDESTK. When I reset UC - issue does not occur.

This is value of SEL0 right after starting the program, before any initialization:

And just to be sure - after first instruction at reset vector:

This makes Machine Check Interrupt when I try to make first erase of dataflash (having all low address space locked and - unintentionally - selected).

Yannek · ‎2020-05-29

Once I get Machine Check Interrupt - I expect to get MSR register value (in csrr1) in order to determine the problem source.

UC gives me the value of MSR=0x8090000.

But, according to RM0403 the bits 0x08000000 and 0x00080000 should always be 0:

So is it really MSR? What is reliabilty of this information?

zambrano.luigi · ‎2020-06-03

Hi Yannek,

I suppose you are using SPC5Studio. If you check _IVOR1(Machine Check Interrupt) implementation in ivor.s, you can see that the 2 parameters passed to the callback function are:

mfspr %r3,570 /* Prepare 1st parameter (MCSRR0) for the callback. */

mfspr %r4,572 /* Prepare 2nd parameter (MCSR) for the callback. */

So, the second parameter of the callback function is the content of the MCSR register and not the content of the MSR register.

Regards,

Luigi

Giovanni CUCE · ‎2020-06-10

Hello Yannek,

please find below some answer for your questions

I found some incosistencies between Reference Manual RM0403 and actual behaviour of SPC582B50 flash registers.

According to RM section 32.3.2.3 to 6 - all LOCKx registers should be set to all-1s after reset.

I observe otherwise:

Using SPC5Studio I have built a new project from scratch and I have checked both LOCKx and SELx register values at the start of the main.

How you can see (pictures below) those values are as expected (default values at reset):

LOCKx -> 0xFFFFFFFF

SELx -> 0x0

In order to better investigate about your issue could you please share you SPC5Studio project?

You can send your project directly to me at the following address:

giovanni.cuce@st.com

I also found that SEL0 register of FLASH_0 module is not initiated to all zeros (as stated in RM0403), but one of bits is set. This happens only after programming UC by JTAG/UDESTK. When I reset UC - issue does not occur.....

Could you please give me more details about your test?

Could you please better explain what means the sentence:

"This happens only after programming UC by JTAG/UDESTK"

What do you do after programming?

Best Regards,

Giovanni

Yannek · ‎2020-06-11

Hi Giovanni,

> Could you please better explain what means the sentence:

> "This happens only after programming UC by JTAG/UDESTK"

> What do you do after programming?

Here are steps I perform:

build the program in SPC5Studio
UDE STK 5.0 loads the program and I upload it into UC (only PFLASH partition). I use SPC5-UDESTK debugger with 256k code limit.
I run the program until breakpoint at the very beginning of main() stops it (as on my screenshot)
I navigate through "locals" tab in order to see values of LOCKx and SELx and I get the results (some zeros in LOCKx, the single one in SEL0)
I press the reset button in UDE STK
I run the program again until the breakpoint.
Now all LOCKx are all-1s and SELx are all-0s (this is correct).

So i meant that it occurs only right after programming the UC. After consecutive resets or power ups - there is no problem.

I will try to simplify my project in order to send it to you (unless the description above would be enough to reproduce the problem).

Good day,

Yannek

Giovanni CUCE · ‎2020-06-15

Hello Yannek,

....some answers

The same sections of RM say:

"The LOCK field is not writable:

– Once an Interlock Write is completed until MCR.DONE is set."

I observe, that write to LOCKx registers (restoring the lock) is not possible right after MCR.DONE is set. I also need to clear MCR.EHV, then I can write to LOCKx registers.

Can you please confirm which one is correct?

Both LOCKx and SELx registers can be restored only after reset of the EHV bit

This will be better detailed in the next version of the RM.

Thanks for your feedback.

Why LOCKx and SELx registers have not default values at reset/beginning of main()?

I tried to replicate the issue but couldn't do it.

Please find below steps I performed:

1) I built a new program in SPC5Studio ( I used a SPC57xxMB + SPC58XXADPT64S minimodule because i have not discovery board available)

2) Using UDE STK 5.0 I loaded the program ( I used SPC5-UDESTK debugger with 256k code limit)

3) I run the program until breakpoint at the very beginning of main() stops it (as on my screenshot)

4) How you can see (see attached screenshot) both LOCKx and SELx registers values are as expected.

Could you please use my test in your environment and let me know if the issue appears.

If not...

Starting from my test could you try to modify it in order to replicate the issue?

Best Regards,

Giovanni

Yannek · ‎2020-06-15

Hi Giovanni,

I don't observe the issue on the project you have sent me.

I will send you mine project (via e-mail). Please check if you will see the problem.

Thank you for the other clarifications.

Best,

Yannek