• State Resolved
  • Locked Locked
  • Replies 7 replies
  • Subscribers 31 subscribers
  • Views 1133 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

TM4C129ENCPDT: TM4C129ENCPDT: Boundary Scan Test Problems on Pin PL7 and Pin PB3

user5820349
Prodigy 90 points
Part Number: TM4C129ENCPDT
Other Parts Discussed in Thread: SEGGER

Hi,

 

i´m trying to perform a Boundary Scan Test on a TM4C129ENCPDT uC on a PCBA. For this, i´m using "CASCON GALAXY 4.6.8c 1578" from GOEPEL electronic with the BSDL Model from the TI Homepage (http://www.ti.com/product/TM4C129ENCPDT/toolssoftware) from 29 Oct 2013.

 

I have problems to control the two pins PL7 and PB3.

 

In my circuit, the PB3 Pin output signal is inverse to the adjustment and I can’t control the PL7 output at all. Both pins are described in the BSDL model as inout signals and have OUTPUT3 cells. All other Boundary Scan pins behave as expected.

 

Currently the TM4C129ENCPDT chip isn´t programmed. A colleague found out that after programming the TM4C129ENCPDT, the PB3 pin behaves as described / expected (non-inverted). But still I can’t control PL7.

 

Is there somebody, who knows about the TM4C129ENCPDT in Boundary Scan Mode, especially about the PL7 and PB3 Pins and uses the BSDL Model from the TI Homepage?

 

Thanks in advance

  • 0
    TI__Guru 72500 points
    Interesting. I think the issue is that on a blank device a ROM bootloader is called. This bootloader will configure the USB port to look for a DFU (Device Firmware Upgrade). The pins that go to the USB bypass the digital IO when configured for use as USB and are therefore not as expected on the BSDL scan chain. When you have code in the device, does it configure the USB port?
  • 0 in reply to Bob Crosby
    Prodigy 90 points
    Sorry for the late reply.
    The software isn´t from me, so i don´t know about the USB port configuration. But the final-device don´t have any USB-Port, so i think the port is not configured.
    There was a good hint with the ROM-Bootloader. When i program the device with the custom hex-file (Bootloader + Firmware) the Boundary-Scan Test works as well.
    Anyway, i need a way to make a Boundary-Scan Test of non-programmed uC.

    I´m expecting there is a way in the boundary-scan-mode to reconfigure the ROM-Bootloader-configuration, for use the BSCAN-GPIO functionality of the pins PL7 and PB3.
    Elsewise is it possible to disable the ROM-Bootloader?

    Thanks in advancer?
  • 0 in reply to user5820349
    TI__Guru*** 135355 points

    Hello,

    It is possible to disable the ROM Bootloader entirely or to have it only triggered by a GPIO pin matching state when the device boots up. These both can be set by committing to the BOOTCFG register with the desired settings.

    See Sections 5.2.2.2, 8.2.2.1, and 8.2.3.12 for details on BOOTCFG and committing to it, and Register 68: Boot Configuration (BOOTCFG), offset 0x1D0 on Page 682 for more information about the BOOTCFG options.

  • 0 in reply to Ralph Jacobi
    Prodigy 90 points
    Hi,

    if I understood this correctly in the data sheet, in all cases data must be at the flash memory address 0x0000.0004 so that the ROM bootloader can be disabled?

    Thanks in advance.
  • 0 in reply to user5820349
    TI__Guru*** 135355 points
    Hello,

    Sorry I listed the wrong page number for BOOTCFG register, it is on Page 682 for your device datasheet.

    No you are not fully understanding correctly. The BOM boot loader can be disabled with other means as well. Here are all the checks which are run:

    1. The BOOTCFG register is read. If the EN bit is clear, the ROM Boot Loader is executed.

    2. In the ROM Boot Loader, the status of the specified GPIO pin is compared with the specified
    polarity. If the status matches the specified polarity, the ROM is mapped to address 0x0000.0000
    and execution continues out of the ROM Boot Loader.

    3. If the EN bit is set or the status doesn't match the specified polarity, the data at address
    0x0000.0004 is read, and if the data at this address is 0xFFFF.FFFF, the ROM is mapped to
    address 0x0000.0000 and execution continues out of the ROM Boot Loader.

    4. If there is data at address 0x0000.0004 that is not 0xFFFF.FFFF, the stack pointer (SP) is loaded
    from Flash memory at address 0x0000.0000 and the program counter (PC) is loaded from
    address 0x0000.0004. The user application begins executing.

    You can commit to BOOTCFG either the EN bit or a GPIO pin to check for polarity, and if that check fails then it will not execute the ROM boot loader.

    Only if both those checks pass, then it will look for the Flash memory.
  • 0 in reply to Ralph Jacobi
    Prodigy 90 points
    I'm sorry, but I do not understand it yet.
    I understand the point 3 on page 682, if the GPIO condition fails and the flash address 0x0000.0004 is 0xFFFF.FFFF, the execution continues with the ROM boot loader.

    The description of the EN bit on page 684 is also not very clear to me.
    I understand like this:
    EN = 0: The defined port pin decides whether the ROM bootloader is executed.
    EN = 1: The content of Flash at location 0x0000.0004 decides if the ROM Boot Loader will be executed.

    If this is true, I find it contradictory with the point 1 on page 682, which says if EN == 0 execute the ROM boot loader.

    I've tried several boot configurations, but failed to boot the ROM boot loader.

    Currently the BOOTCFG register 0x400F.E1D0 has the value 0xFFFF.00FE.
    My hope was to pull the GPIO pin PA0 (33) low to prevent the ROM bootloader. It did not work.

    If I understood it correctly, you need to do the steps described in chapter 4.3.4.3 Recovering a Locked Microcontroller to restore the default values for the BOOTCFG register?
    Looks pretty complex for me.

    I think there must be a more elegant way to prevent bootloader booting. I have seen that the Segger j-link programmer can trigger a reset of the module and then the module remains in a "halt" mode.
    I think j-link writes "SYSRESREQ" and maybe "VECTRESET" in the "APINT" register on page 178.
    I tried to write the value 0x05FA.0005 into the APINT register 0xE000.ED0C. My hope was that a reset will be triggered. So far it has not happened. I also do not know how to use the Interrupt Priority Levels.
    Can someone help me with this?
  • 0 in reply to user5820349
    Prodigy 90 points
    I will put my questions in new threads. I think the question why the pins PL7 and PB3 can not be controlled in the B-SCAN has already been answered.

    Many Thanks