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.

UCD3138A: abort_prefetch_exception interrupt as soon as MiscAnalogRegs.IOMUX.all = 0; is executed

Part Number: UCD3138A
Other Parts Discussed in Thread: UCD3138

hi,

I've got problem as in topic, device goes to abort_prefetch_exception interrupt as soon as MiscAnalogRegs.IOMUX.all = 0; is executed. I did try to compile in 16 and 32 bit mode.

I want to set GPIO for test and on each of those commands id hands in abort_prefetch_exception 

    MiscAnalogRegs.IOMUX.all = 0;
    MiscAnalogRegs.GLBIOEN.bit.DPWM3A_IO_EN = 1;        // Set DPWM3A as GPIO
    MiscAnalogRegs.GLBIOOE.bit.DPWM3A_IO_OE = 1;        // 1 = output, 0 = input
    MiscAnalogRegs.GLBIOVAL.bit.DPWM3A_IO_VALUE = 1;    // Set output to high

I did compile simple program and it works:

main{

volatile int i =0;

while(1)

    i = i+1;

}

I use TI v5.2.9 compiler and I did change Variant from Generic ARM7 device to UCD3138A

I've got same error on Lab1 example, untouched example file only the Linker command File changed from cyclone_headers.cmd to cyclone.cmd

  • I might need some more information.  How do you know that it's the MiscAnalogRegs.IOMUX.all = 0; that's causing the issue, not something before or after?  

    I'd suggest putting I/O toggling in your simple program to make sure that it's actually getting there and continuing to run.  Sometimes it can get in a loop where it doesn't go to ROM mode but doesn't run quickly.  

    If it's not running, how do you know that you're getting to the abort prefetch exception?

    Are you using one of our EVM boards?  I ask this because if you enable the JTAG by putting a 0 into IOMUX, you have to have the TCK pin pulled to whatever state the EVM board pulls it to.  If it's floating, it can start clocking the JTAG logic, which isn't good.  

    Why are you changing the linker command files, and what exzctly are you changing?  What device are you using?  

    Abort prefetch exception means that the program counter is somehow pointing at invalid memory.  We generally only see that if there is a big code error, like a function pointer going wrong, or if the board is really noisy and the CPU gets bits modified by the noise.  Or perhaps if TCK is being clocked?  We've never seen that yet, but there's always a first time.  

    I'm sorry I don't have a single advice to give you, but this is a weird one.

    If it is going to ROM mode, especially in the lab code, it may be that you need to pull an I/O line high or low.  There is an if statement very early in main that looks at one or more I/O lines and clears the checksum and resets the part depending on the state of the I/O line.

    Some of our old codes, when they clear the checksum, reset by deliberately going to an invalid address.  This will give you that exceptiom. Now we recommend writing to the RESET bit in the SYSECR register:

    SysRegs.SYSECR.bit.RESET = 2;   //now reset processor.

    This has to be done in privileged mode, meaning some kind of interrupt, or you will get an illegal write exception.  

    I hope at least one of these suggestions are helpful.  

    Whatever you do, don't program the checksum.  You may just put it in an infinite loop of resets, which will lock up the processor, and you'll have to get another.  

  • I'm using 40 pin UCD3138 which has no fault 3 pin connected = it is easy to brick it with your default settings...

    so I did a test: I've got CCS 6.2 installed along with 10.3

    1. I did install the training labs to new folder,

    2. In CCS: import project, properties: Generic ARM7 Device -> UCD3138, cyclone_headers.cmd -> cyclone.cmd, default TI compiler v5.2.5, build project

    3. In device gui: scan device in ROM mode: Found ROM v2 IC v3 - UCD3138 Rev2, firmware download: 
     Starting download ...
     Parsing firmware file ...
     Mass erasing program flash
     Downloading program flash ...
     Verifying program flash ...
     Having ROM calculate checksum for program flash 0x10000 through 0x17FFB ...
     Program Flash checksum match between GUI calculation and Rom calculation (0x0073A9EF)
     Download completed without error; 2.0 sec elapsed
     Looking for device in ROM mode ...
     Checking if ROM is still present ...
     Reading Dev ID Register ...
     ROM v2 IC v3 detected

    4. in device gui: command ROM to execute its program

     Looking for device in ROM mode at address 11d ...
     Reading ROM version ...
     Found ROM v2 IC v3 - UCD3138 Rev2
     Scanning addresses 1-11,13-127 for program mode devices 
     No devices found

    In the attachment you can find the project:
    Lab_01.zip 

  • I did make a progress, it seems that I had two issues at once:

    1. I was using a blank project form tutorial: CCS6 Project Setup Tutorial for UCD3138 Family I did abandon this approach and I did copy paste in project explorer of CCS the lab01 example and start to work on it, this cured abort_prefetch_exception 

    2. in 40pin enclosrure the fault3 pin is not physically connected to enclosure and it is read "high": program get stuck in clearing the checksum on each boot

    commentig out or changing to fault 2 fixes the issue

    if(GioRegs.FAULTIN.bit.FLT2_IN == 1)
    {
    clear_integrity_word();
    }