This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

UCD3138 Family - how to make sure the checksum can be cleared and you can return to ROM mode

Other Parts Discussed in Thread: UCD3138, UCD3138064, UCD3138064A, UCD3138A64A, UCD3138128A, UCD3138A

Here are a few pointers to common problems that people have with returning to ROM mode from flash mode on the UCD3138 family of devices. 

First a little background.  The UCD family devices power up in ROM mode.  The ROM reads the program flash and checks several checksums for different areas of the flash.  If any of the checksums are valid, the ROM configures the Flash and jumps to the program in the flash.  The only way to stay in ROM mode (for example if you want to reprogram the flash) is to have something in the flash that makes the checksum invalid.  To do this, you need a program to write to the program flash and/or the flash control registers

This program cannot be executed from the program flash.  This is because when the flash is written to or erased, it doesn't return valid instructions until the process is over.  It will just return all Fs.  In our EVM codes, we copy the checksum clearing program into RAM and execute from there.  This isn't perfectly straightforward, and there are some pitfalls - here is a list of some of them:

1. The program which is copied into RAM should be compiled in its own file, and the processor mode should be set to 32 bit (ARM) mode instructions. 

This is done by right clicking on the specific file name in CCS and selecting "Show Build Settings".  Then select ARM Compiler->Processor Options->Designate Code State, and select 32 bits.

If you don't select this, the proper code may not be copied into the proper location.  The software interrupt code used to copy from program flash to RAM starts at the ARM mode entry point.  If the function is compiled in 16 bit, the 32 bit entry point will be just a 32 bit wrapper that switches to 16 bit mode, calls the 16 bit function, and then switches back to 32 bit mode and returns.  The linker may not put the 32 bit wrapper anywhere near the 16 bit function.  Sometimes it will, so everything will work, sometimes it won't, and things will stop working. 

2.  Make sure that the rest of the program is working before you program the checksum.  For development work, it is generally not necessary to write the checksum.  You can always use the GUI to tell the program to start running.  Before setting the checksum with a new program, test the checksum clearing function.  This is pretty quick:

1. download the code to the device, making sure that the checksum is not being written
2. Close the download window and return to the main window
3. Click on DEVICE ID
4. ClIck on COMMAND PROGRAM TO JUMP TO ROM
5. Click on the Checksums tab.
6. Click on Validate
7. It should return that the checksum is invalid. If it is invalid because it is all zeroes, that's good, your code is working correctly and clearing it. If it is invalid because it is all FFs, that is bad, because your code is not working correctly and not clearing the checksum
8. If the checksum is all zeroes, go ahead and click Recreate.
9. If the checksum is all FFs, try to fix your code and run the test again.

Note:  This works on all EVM codes so far.  The EVMS only clear the checksum - this is good for development.  For a production code, it is better to erase the entire Program flash for IP security.  In this case the checksum will be all FFs.  But so will the rest of the flash.  For this situation, for step 5, click on Command ROM to execute its program.  If it finds a DEVICE ID, then the flash clear isn't working.  If it doesn't find a device ID, and is back in ROM mode, you're good. 

  • Dear Mr. Bower,

    It has been now almost 6 months since I've started a project for a custom 3KW AC<>DC<>AC Rectifier/Inverter.
    I opted for the UCD3138064RGC due the feature of updating the firmware online.
    One application for this is in Telco cabins. They can run up to 48 in parallel.

    I have had tremendous difficulties with any kind of support from your company. Everything is either too vague, unexplained or obsolete (CCS3).
    I have very long experience in programming and hardware design, since 1970!
    But now i got stuck into this controller and all my deadlines are already gone.

    Just one client is requiring 60K products to be delivered in the next 4 months. I have first to get approvals through the government agencies, and the manufacturing takes 2 months .
    I managed to grab the PFC firmware and have already made all necessary adaptations required either to run it on the 3138064 and in my specific hardware.

    Trouble is:
    Fusion does not recognizes my firmware file even if I define it correctly in pmbus.h:
    The hardware is working fine since the CPU enters ROM mode and Fusion recognizes the device as:
    UCD3138064 Rev1
    ROM v1 and IC v4
    64-pin
    All flash tests work fine, it uploads flash and data correctly but THE CHIP DOES NOT RUN and reboots to ROM mode.
    All compiled in 32bit mode, etc etc.

    Timestamp Message
    21/01/2016 17:16:02 User continuing with download with ROM although the device id could not be recognized. A valid device id would be for example: UCD3000ISO1,UCD3100ISO1,UCD310064V1,UCD310128V1,UCD310A64V1,UCD3138A,UCD3138064A,UCD3138128A,UCD3138A64A. Informações válidas devem ser especificadas para analisar a cadeia de caracteres.
    21/01/2016 17:16:02 Firmware download options:
    21/01/2016 17:16:02 File: C:\ti\projects\R2K5EX\R2K5EX\Debug\R2K5EX.x0
    21/01/2016 17:16:02 Download program flash: Download
    21/01/2016 17:16:02 Download data flash: Download
    21/01/2016 17:16:02 Send to program mode when done: False
    21/01/2016 17:16:02
    21/01/2016 17:16:02 Starting download to block 0 ...
    21/01/2016 17:16:02 Parsing firmware file ...
    21/01/2016 17:16:02 Firmware is in Tektronix Extended format
    21/01/2016 17:16:02 Mass erasing program flash block 0
    21/01/2016 17:16:02 Downloading program flash ...
    21/01/2016 17:16:09 Mass erasing data flash
    21/01/2016 17:16:09 Downloading data flash ...
    21/01/2016 17:16:09 Verifying program flash ...
    21/01/2016 17:16:09 Having ROM calculate checksum for program flash 0x40000 through 0x47FFB ...
    21/01/2016 17:16:10 Program Flash checksum match between GUI calculation and Rom calculation (0x006B4FEE)
    21/01/2016 17:16:10 Verifying data flash ...
    21/01/2016 17:16:10 Reading data flash ...
    21/01/2016 17:16:11 Data Flash verified!
    21/01/2016 17:16:11 Download completed without error; 11.5 sec elapsed
    21/01/2016 17:16:11 Sending ROM execute flash command (SendByte 0xF0 to 11)
    21/01/2016 17:16:11 Executing program ...
    21/01/2016 17:16:13 Scanning for programs that respond to a DEVICE_ID read ...
    21/01/2016 17:16:13 Looking for device in program mode ...
    21/01/2016 17:16:14 No PMBus devices responded to a DEVICE_ID request
    21/01/2016 17:16:14 Checking if ROM is still present ...
    21/01/2016 17:16:14 Reading Dev ID Register ...
    21/01/2016 17:16:14 ROM v1 IC v4 detected

    If you can provide any help, I would really appreciate, otherwise I'm stuck.

    Thanks in advance,

    Eduardo Prado
  • Eduardo, you've got me beaten on years, I wrote my first program in 1973.  There are lots of things that could cause your program to go to reset.  Any read from an illegal address would do it, for example.  

    Since you make a specific mention of the 3138064 and getting the GUI to recognize it, I suspect that you started with the UCD3138 version of the code and converted it to '064?  

    If so, are you using the '064 header and linker files?  Many of the peripherals are moved in the '064 compared to the 3138.

    There should be a file called cyclone_headers.cmd.  On the UCD3138, it has this:

    .......

      LOOP_MUX    : origin = 0x00020000, length = 0x78     /* Loop Mux Registers       */

      FAULT_MUX   : origin = 0x00030000, length = 0x80     /* Fault Mux Registers      */ .......

    For the 064, it will show this:

    ......

      LOOP_MUX    : origin = 0x00120000, length = 0x78     /* Loop Mux Registers       */

      FAULT_MUX   : origin = 0x00130000, length = 0x80     /* Fault Mux Registers      */

    There are changes to addressing and some changes to the peripheral registers as well. 

    You need to use the linker files and header files for the 064 instead of the 3138

    There are other changes which also need to be made other than just the header and linker files. 

    If you search for "UCD3138064 Programmer’s Manual", you will find a guide to porting code from the UCD3138 to the UCD3138064.

  • Dear Ian,
    After a long struggle I managed to get the last LLC source. Now working on CCS6!
    Managed to compile and upload to the CPU and i think from now on it is on me :D.
    Obviously before even starting this project I analized all topologies and solutions available.
    The requirements are 3KW @96% efficiency at least.
    All documentation on the UDC3138 and pertinent lab series were studied and I found that this chip could be a solution.
    This particular project uses DPWM0 for PFC/Inverter, DPWM1 for Isolated Rectifier/Chopper, DPWM2 for Output/Input Buck and DPWM3 for Solar DC input.
    It is build in such a manner that it works both ways, as a 3KW 240VAC 48V/50A Rectifier OR Inverter.
    But the good news: I managed to compile and upload the default LLC !!! as shown below:

    Timestamp Message
    22/01/2016 10:46:09 USB Adapter v1.0.10 [PEC; 400 kHz; Alert: Open Drain; Clock: Open Drain; Data: Open Drain] Found (Adapter #1)
    22/01/2016 10:46:09 Looking for device in ROM mode ...
    22/01/2016 10:46:09 Reading Dev ID Register ...
    22/01/2016 10:46:09 ROM v1 IC v4 detected
    22/01/2016 10:46:09 Ready to download firmware
    22/01/2016 10:46:36
    22/01/2016 10:46:36 Firmware download options:
    22/01/2016 10:46:36 File: C:\ti\projects\LLCHBFirmware-1.2\Firmware\LLC\LLC_HB\UCD3138064\UCD3138_LLC_HB_UCD3138064.x0
    22/01/2016 10:46:36 Download program flash: Download
    22/01/2016 10:46:36 Download data flash: Download
    22/01/2016 10:46:36 Send to program mode when done: False
    22/01/2016 10:46:36
    22/01/2016 10:46:36 Starting download to block 0 ...
    22/01/2016 10:46:36 Parsing firmware file ...
    22/01/2016 10:46:36 Firmware is in Tektronix Extended format
    22/01/2016 10:46:37 Mass erasing program flash block 0
    22/01/2016 10:46:37 Downloading program flash ...
    22/01/2016 10:46:46 Mass erasing data flash
    22/01/2016 10:46:46 Downloading data flash ...
    22/01/2016 10:46:47 Verifying program flash ...
    22/01/2016 10:46:47 Having ROM calculate checksum for program flash 0x40000 through 0x47FFB ...
    22/01/2016 10:46:48 Program Flash checksum match between GUI calculation and Rom calculation (0x003E0134)
    22/01/2016 10:46:48 Verifying data flash ...
    22/01/2016 10:46:48 Reading data flash ...
    22/01/2016 10:46:48 Data Flash verified!
    22/01/2016 10:46:48 Download completed without error; 12.4 sec elapsed
    22/01/2016 10:46:48 Sending ROM execute flash command (SendByte 0xF0 to 11)
    22/01/2016 10:46:48 Executing program ...
    22/01/2016 10:46:51 Scanning for programs that respond to a DEVICE_ID read ...
    22/01/2016 10:46:51 Looking for device in program mode ...
    22/01/2016 10:46:52 Found DC-DC LLC Firmware v0.0.11.106 @ Address 89d in program mode

    Thank you for your support.
    Eduardo
  • In some of version EVM code, we copied 500 words from pflash to ram to run the zero_out_integrity_word in ram. Please see the below code in one of our example code:
    case 12: // clear integrity word.
    {
    {
    register Uint32 * program_index = (Uint32 *) 0x19000; //store destination address for program
    register Uint32 * source_index = (Uint32 *)zero_out_integrity_word; //Set source address of PFLASH;

    register Uint32 counter;

    for(counter=0; counter < 500; counter++) //Copy program from PFLASH to RAM
    {
    *(program_index++)=*(source_index++);
    }
    }
    {
    register FUNC_PTR func_ptr;
    func_ptr=(FUNC_PTR)0x19000; //Set function to 0x19000
    func_ptr();
    } //execute erase checksum

    return;
    }

    The risk of copying 500 words is that the program_index pointer would points to illegal address if zero_out_integrity_word is assigned to address that above 0x0000 782F(UCD3138 32KB device). Under this condition, the device will get reset or enter into abort exception mode while the program_index points to out of pflash.

    A way of grantee to avoid this problem is that just copy the size of zero_out_integrity_word from flash to ram.
    Here is the steps of implementing this solution:
    1. In cyclone.cmd file, add a group section like this:
    SECTIONS
    {

    … …
    UNION : run = RAM, RUN_START(_ram_run_start)
    {
    .zero_out_integrity_word_0 : load = PFLASH,
    LOAD_START(_zero_out_integrity_word_start),
    LOAD_END(_zero_out_integrity_word_end),
    LOAD_SIZE(_zero_out_integrity_word_size)
    }
    … …
    }
    2. Clarify those symbols in header file or at the beginning of the source file referenced
    extern Uint8 zero_out_integrity_word_start, zero_out_integrity_word_end, zero_out_integrity_word_size;
    extern Uint8 ram_run_start;

    3. Use a program to allocate the function into the section defined in above.
    #pragma CODE_SECTION(zero_out_integrity_word, ".zero_out_integrity_word_0")
    void zero_out_integrity_word(void)
    {

    DecRegs.FLASHILOCK.all = 0x42DC157E;// Write key to Program Flash Interlock Register
    DecRegs.MFBALR1.all = MFBALRX_BYTE0_BLOCK_SIZE_32K; //enable program flash write
    program_flash_integrity_word = 0;
    DecRegs.MFBALR1.all = MFBALRX_BYTE0_BLOCK_SIZE_32K + //expand program flash out to 4x real size
    MFBALRX_BYTE0_RONLY;
    while(DecRegs.PFLASHCTRL.bit.BUSY != 0)
    {
    ; //do nothing while it programs
    }
    // interrupt_time = TimerRegs.T24CNTDAT.bit.CNT_DAT - interrupt_time;
    SysRegs.SYSECR.bit.RESET = 2; //now reset processor.
    return;
    }

    4. Use memcpy function to copy the code from flash into ram, and then call the function directlly.
    case 12: // clear integrity word.
    {
    memcpy((void *)&ram_run_start, (void *)&zero_out_integrity_word_start, (int32)&zero_out_integrity_word_size);
    zero_out_integrity_word();
    return;
    }

    There are several advantages of using this way,
    - No need to consider the instruction set switch from ARM to Thumb.
    - No worries about don’t have copied the whole code or more than the code itself into ram

    Regards,
    Jack Tan
  • Hi,

    I also stuck now.

    I can run my Software on the EVAL board, connected this board by a squid cable to the EVAL board.

    Now I want to use my own board. This time programming Fails. I can run Flash and data Memory test without Errors, but the chip didn't want to execute the Software.

    Crazy, whats the difference using the EVAL board and my board?

    Thanks for helpuing.

    Gerhard

  • Oh my god. Missing pullup on TMS line and the 'backdoor trick' doing it ....

    Maybe configuring the TMS line as Input WITH INTERNAL PULLUP is one line of code more, but helps a lot. A patch of all the samples will be appreacheated.

    Thanks.

    With best regards

    Gerhard