UCD3138 LLC firmware UCD3138FBLLC_CCS6 configuration data flash

hakan aydin

Other Parts Discussed in Thread: UCD3138

We are using the full-bridge LLC firmware as a reference. We were trying to set very simple parameters from the GUI, permanently (in the dflash). For example, VOUT. When we tried this several times, we found out that the vout setting is never being restored properly. It only changes the setting until the next power cycle.

Looking at the code in more detail, I do not see anywhere where the configuration parameters are written and read from the flash. It looks like all the functions read/write constant values.

For example restore_default_all() in store_restore_functions.c, does not appear to read anything from the flash, instead, looks like it copies from the constant pmbus_dcdc_config_constants[0]

Similarly, pmbus_write_store_default_all() function in pmbus_cml_commands.c, does not appear to write anything to the flash at all. First of all, there is no ERASE command sent to the flash, which is strange. Then the data setup to be written is not the data in pmbus_dcdc_config, rather, it is the constant data in pmbus_dcdc_config_constants.

I hope I am wrong about all this but I do not see how this firmware and software can set these values in dflash properly.

Can you please help?

over 7 years ago

0 Ian Bower over 7 years ago

TI__Genius 17090 points

Pmbus_dcdc_config_constants[0] is actually in data flash.
There are two blocks of data flash used. One is always kept erased.
The sequence is that the store default all writes to the already erased block, and then starts a state machine to erase the block with the previous data in it.
If you write to Vout, and then do a store default all command, you should get the new vout the next time you power up.

0 hakan aydin over 7 years ago in reply to Ian Bower

Intellectual 470 points

Hello,

We never get the correct Vout after a write to vout followed by store default to all, hence this post.

We do see the vout change when we perform a write, and then store_default_all claims that it finished successfully, but next power-up ends up with the default VOUT settings. Is the memcpy at around line 132 in store_restore_functions.c intended to do the copy from flash to RAM?:

memcpy((void *)&pmbus_dcdc_config[0], (void *)dcdc_config_ptr, sizeof(pmbus_dcdc_config_constants));

pmbus_dcdc_config_constants[0] is defined in pmbus_cml_commands.c, around line 32 as:

extern volatile const PMBUS_DCDC_CONFIG pmbus_dcdc_config_constants[DCDC_PAGE_NUMS];

... and in constants.c, around line 60, we have:

#pragma DATA_SECTION(pmbus_dcdc_config_constants, ".CONFIG")
volatile const PMBUS_DCDC_CONFIG pmbus_dcdc_config_constants[DCDC_PAGE_NUMS] = {DEFAULT_PMBUS_DCDC_1_CONFIG};

The DEFAULT_PMBUS_DCDC_1_CONFIG is declared in pmbus.h, around line 652:

#define DEFAULT_PMBUS_DCDC_1_CONFIG  {\
VOUT_0, \
VOUT_OV_FAULT_LIMIT, \
VOUT_OV_WARN_LIMIT, \
VOUT_UV_FAULT_LIMIT,\
...
...
\}

In our system, when we apply power to the system, VOUT is ALWAYS set to the VOUT_0 constant in the DEFAULT_PMBUS_DCDC_1_CONFIG constant.

So either the write, or the read is failing in our system, but neither appear to fail. Any ideas how we can debug this problem?

0 Jack Tan80 over 7 years ago in reply to hakan aydin

Mastermind 7090 points

Please do some configurations via below 2 steps:

1. Changes to software interrupt, the SWI entry in some of the demo EVM looks like as below:

#pragma INTERRUPT(software_interrupt,SWI)
void software_interrupt(Uint32 arg1, Uint32 arg2, Uint32 arg3, Uint8 swi_number)
//void software_interrupt(Uint32 *address, Uint32 data, Uint32 more_data, Uint8 swi_number)
{
//make sure interrupts are disabled
asm(" MRS r4, cpsr "); // get psr
asm(" ORR r4, r4, #0xc0 "); // set interrupt disables
asm(" MSR cpsr_cf, r4"); // restore psr

switch (swi_number) //handle flash write/erase and ROM backdoor first

…

}

With some codes and newer versions of the compiler, the compiler is moving a parameter in the software interrupt call into R4, which is then corrupted by the write to the CPSR to disable the interrupts. The safest is to push R4 onto the stack disable the interrupts, and then pop it again when done:

So the entry of SWI should be changed as below:

//make sure interrupts are disabled

asm(" STMFD SP!, {R4} "); //Store R4

asm(" MRS r4, cpsr "); // get psr

asm(" ORR r4, r4, #0xc0 "); // set interrupt disables

asm(" MSR cpsr_cf, r4"); // restore psr

asm(" LDMFD SP!, {R4} "); //Restore R4

2. The MFBALR2 register is designed to word write only, Byte and Half word writing to this register will cause a problem. So it’s highly recommended to use write word to this register while enabling dflash to write. Please update it with using the new code.

Original code:

DecRegs.MFBALR2.bit.RONLY = 0; //clear RONLY bit

DecRegs.MFBALR2.bit.RONLY = 1; // set RONLY bit

New code:

DecRegs.MFBALR2.all &= ~(1<<1); // clear RONLY bit

DecRegs.MFBALR2.all |= (1<<1); // set RONLY bit

Hope it helps you.

0 hakan aydin over 7 years ago in reply to Jack Tan80

Intellectual 470 points

Thank you, but unfortunately, did not seem to help.

0 Ian Bower over 7 years ago in reply to hakan aydin

TI__Genius 17090 points

I've been working on related issues, and I've got another thing to try. Sometimes there is an issue with using bitfields with the MFBALR registers. They only like being written to with full 32 bit words. The newer versions of the compiler tend to get more and more clever and willing to write half word and byte wide patterns, which can cause problems.

If you look at software_interrupts.c or interrupts.c, you will see a case that says write word to data flash.

It's got lots of bit mapped writes to MFBALR2 wrapped around the write to data flash:

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

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

DecRegs.MFBALR2.bit.RONLY = 1;

You can delete all the lines that start with DecRegs if you also delete some lines in load.asm, or maybe load(device name here).asm.
The lines you need to delete in load.asm are:

LDR r0,c_mfbalr2_half0_load ;set up data flash for write only
STRH r0,[r4,#8] ;put it into mfbalr2

All this code is to add a read only bit to the data flash to provide protection beyond the flash key to prevent writes to the data flash.
It's not really necessary, and it may be causing your problem.

0 Ian Bower over 7 years ago in reply to Ian Bower

TI__Genius 17090 points

I kept working through the software interrupt, and you also want to take out the RONLY bit modifications in case 13. That's the code that actually writes to the data flash for the store default all.

0 Kami Huang40 over 7 years ago in reply to Ian Bower

Prodigy 175 points

Hi Ian
May I ask a simply question about *.cmd? I don't understand
SECTIONS {
.xxx : {} > 0x123023
.xxxx : {} > (xxLASH align(16))
.xxxx : {} > (DEVICEID)
.xxxx : {} > label1
.xxxx : {} > label2
means?
Best Regards,
Kami Huang

0 Ian Bower over 7 years ago in reply to Kami Huang40

TI__Genius 17090 points

Did my latest suggestions solve the store default all issue?

As for your latest question, it's pretty complicated. If you want to give me specific commands with real values on the left hand side, I can tell you want the specific ones do.

The best way to understand the whole process is to look at chapter 8 of the arm 7 assembly tools user's guide, which is here:

0 Kami Huang40 over 7 years ago in reply to Ian Bower

Prodigy 175 points

Hello Ian

I very want to provide provide real value to you if I don't get TI warring phone call about issue code on TI E2E. Please allow me to study pdf file what you provide? The relative data is in chapter 8. Thank for your kindly help.

Best Regards,

Kami Huang

0 hakan aydin over 7 years ago in reply to Ian Bower

Intellectual 470 points

Hello Ian,

Looks like my thread has been hijacked with another subject. I just wanted to report that, yes, your last suggestion worked, and we can now store to flash.

Thanks

0 hakan aydin over 7 years ago in reply to Ian Bower

Intellectual 470 points

Dear Ian,

By the way we also have problems with the LLC "store to flash" code. I made all the changes that you suggested for the PFC to the LLC as well, but we still can not store to flash with the LLC firmware. We were able to get it running with the PFC with your suggestions, but LLC probably needs more changes. Any ideas?

Best,

0 Ian Bower over 7 years ago in reply to hakan aydin

TI__Genius 17090 points

I assume you are using the LLC code from the web? What device, version of CCS, and compiler version are you using?

0 hakan aydin over 7 years ago in reply to Ian Bower

Intellectual 470 points

Hello,

We received the LLC code from TI a while ago. I believe we got it via Brandon Vonk. If there is some identifying revision information in the code, I can send it to you to verify.

The device is UCD3138, CCS version is 6.1.0. Compiler version in project settings is TI v5.2.4 [TI 5.2.2]

Thanks

0 hakan aydin over 7 years ago in reply to hakan aydin

Intellectual 470 points

Since store to flash now works in PFC, but not in LLC, I tried to copy the compiler settings from the PFC to project to the LLC project, but the project doesn't even build. Here are the errors I get when I set the LLC compiler to TI v4.9.5 from TI v.5.2.2

"interrupts.asm", ERROR! at line 729: [E0002] Illegal mnemonic specified
MRS r0, spsr

"interrupts.asm", ERROR! at line 731: [E0003] Unexpected trailing operand(s)
BIC r0, r0, #0x1F

"interrupts.asm", ERROR! at line 733: [E0003] Unexpected trailing operand(s)
ORR r0, r0, #0x10

"interrupts.asm", ERROR! at line 735: [E0002] Illegal mnemonic specified
MSR spsr_cf, r0

"interrupts.asm", ERROR! at line 742: [E0002] Illegal mnemonic specified
MRS r0, spsr

"interrupts.asm", ERROR! at line 744: [E0003] Unexpected trailing operand(s)
BIC r0, r0, #0x1F

"interrupts.asm", ERROR! at line 746: [E0003] Unexpected trailing operand(s)
ORR r0, r0, #0x13

"interrupts.asm", ERROR! at line 748: [E0002] Illegal mnemonic specified
MSR spsr_cf, r0

"interrupts.asm", ERROR! at line 771: [E0002] Illegal mnemonic specified
MRS r0, spsr

"interrupts.asm", ERROR! at line 773: [E0200] Offset out of range, must be 5
bit immediate
ORR r0, r0, #0x80

"interrupts.asm", ERROR! at line 773: [E0003] Unexpected trailing operand(s)
ORR r0, r0, #0x80

"interrupts.asm", ERROR! at line 775: [E0002] Illegal mnemonic specified
MSR spsr_cf, r0

"interrupts.asm", ERROR! at line 782: [E0002] Illegal mnemonic specified
MRS r0, spsr

"interrupts.asm", ERROR! at line 784: [E0200] Offset out of range, must be 5
bit immediate
BIC r0, r0, #0x80

"interrupts.asm", ERROR! at line 784: [E0003] Unexpected trailing operand(s)
BIC r0, r0, #0x80

"interrupts.asm", ERROR! at line 786: [E0002] Illegal mnemonic specified
MSR spsr_cf, r0

"interrupts.asm", ERROR! at line 793: [E0002] Illegal mnemonic specified
MRS r0, spsr

"interrupts.asm", ERROR! at line 795: [E0200] Offset out of range, must be 5
bit immediate
ORR r0, r0, #0x40

"interrupts.asm", ERROR! at line 795: [E0003] Unexpected trailing operand(s)
ORR r0, r0, #0x40

"interrupts.asm", ERROR! at line 797: [E0002] Illegal mnemonic specified
MSR spsr_cf, r0

"interrupts.asm", ERROR! at line 804: [E0002] Illegal mnemonic specified
MRS r0, spsr

"interrupts.asm", ERROR! at line 806: [E0200] Offset out of range, must be 5
bit immediate
BIC r0, r0, #0x40

"interrupts.asm", ERROR! at line 806: [E0003] Unexpected trailing operand(s)
BIC r0, r0, #0x40

"interrupts.asm", ERROR! at line 808: [E0002] Illegal mnemonic specified
MSR spsr_cf, r0

0 hakan aydin over 7 years ago in reply to hakan aydin

Intellectual 470 points

Any information? We're still unable to "store to flash" with the LLC firmware (PFC is OK)

0 Ian Bower over 7 years ago in reply to hakan aydin

TI__Genius 17090 points

I haven't forgotten about you, its just been busy. I finally downloaded the LLC code from the TI website and compiled it on CCS 6.1.3.00034
I used 5.2.5 emulating 5.2.4. I downloaded it and it worked fine. I downloaded it from here:

www.ti.com/.../ucd3138fw_llc

You should be able to get it too. Can you try it and see if it works for you with no changes?

0 hakan aydin over 7 years ago in reply to Ian Bower

Intellectual 470 points

We're using the Full Bridge firmware.

Power management

Power management forum

UCD3138 LLC firmware UCD3138FBLLC_CCS6 configuration data flash