UCD3138A: data flash write resets cpu

Tomasz Ciesla

Intellectual 650 points

Part Number: UCD3138A

hi,

I want to use data flash to store variables, I did test erase using SW int wrapper from examples:

erase_dflash_segment_no_delay(0);

it works fine, before erase the segment was filled with 0xAA, after 0xFF (checked with pmbus debug -> memory dump)

then after few seconds of wait I try to write some test data using:

write_data_flash_word(0x18800,0x1);

but after executing it the cpu goes to rom, I assume due to reset. After commanding it to execute pflash, the data flash memory is still 0xFF - no write did occure

I did try to add: disable_fast_interrupt(), disable_interrupt() and set_supervisor_mode() before the write, but without any success... same goes with write_data_flash_block()

I upload FW thru pmbus with option: skip data flash ticked.

have you got any idea what is going wrong?

small update:

write_data_flash_word(0x18800,0x1); in lab1 example in ccs10.3 (which I'm using) resets cpu

I did install lab examples to new folder and opened lab1 in ccs 6.2 and add write_data_flash_word(0x18800,0x1) to main and it works as intended so it looks like the problem is with ccs, I use ti compiles TI5.2.9 in both ccs

over 2 years ago

0 Ian Bower over 2 years ago

TI__Genius 17090 points

Tomasz, I suspect the read only bit for the data flash may be getting set in load.asm and not cleared in the software interrupt. Or the compiler may be using a byte write to write to the register to clear the data flash address setting register.

The code probably looks something like this:

//this clears read only bit to permit writes to data flash.
DecRegs.FLASHILOCK.all = 0x42DC157E; //unlock flash write
//DecRegs.MFBALR2.bit.RONLY = 0;
//put data in word.
*(Uint32 *)(arg1 & 0xfffffffc) = arg2 ;
//DecRegs.MFBALR2.bit.RONLY = 1;

The lines highlighted in red are the ones which turn the read only bit on and off. If it is on, writing to the data flash, even in privileged mode, can cause a reset.

It's an extra level of protection that's not really needed.

Even if the lines are present, there's a risk that the compiler will optimized to a byte write, which the DegRegs are not designed to accept.

To deal with this issue, I suggest putting in a

DecRegs.MFBALR2.all = 0x22;

in place of the first DecRegs write.

This will put the correct value in the MFBALR2, and prevent the compiler from using a byte write.

I would comment out the second write to the RONLY bit, since it's not really necessary. We've taken this protection level out of our more recent codes, since the only way the Data Flash gets written is through the SWI. We actually but the RONLY bit into a very early version of the chip which didn't have the flash key.

+1 Tomasz Ciesla over 2 years ago in reply to Ian Bower

Intellectual 650 points

Sorry, but I did realize that CCS 6.2 has compiler 5.2.5 which works with Lab1 code + write_data_flash_word(0x18800,0x1);

CCS 10.3 uses 5.2.9 which does not work with Lab1 + write_data_flash_word(0x18800,0x1);

I did copy the SW interrupt function from the 026 eval board:

//this clears read only bit to permit writes to data flash.
DecRegs.FLASHILOCK.all = 0x42DC157E;

//DecRegs.MFBALR2.bit.RONLY = 0;                        //does not work
DecRegs.MFBALR2.all &= ~(1<<1); // clear RONLY bit      //works

//put data in word.
*(Uint32 *)(arg1 & 0xfffffffc) = arg2 ;

//DecRegs.MFBALR2.bit.RONLY = 1;                        //does not work
DecRegs.MFBALR2.all |= (1<<1); // set RONLY bit         //works

while(DecRegs.DFLASHCTRL.bit.BUSY != 0) { }
return;

code works only with clearing/setting bit RONLY only as in 026 example using &=, using commented out: DecRegs.MFBALR2.bit.RONLY = 0; resets cpu, maybe there's a conflict with 32 bit code execution somewhere, since project is configured for 16 bit

Since I'm using UCD3138A I did try to add those settings after flash unlock command, but they cause cpu reset

DecRegs.MFBALR2.bit.BLOCK_SIZE =2;
DecRegs.MFBALR2.bit.ADDRESS = 0x22;

after replacing them with direct bit access it works

DecRegs.MFBALR2.all &= ~0x30F;
DecRegs.MFBALR2.all |= 0x8820;

pointing ccs10.3 to compiler 5.2.5 installed with ccs6.2 and building with older 5.2.5 solves the problem of DecRegs.MFBALR2.bit.RONLY = 0

Power management

Power management forum

UCD3138A: data flash write resets cpu