• State Resolved
  • Locked Locked
  • Replies 12 replies
  • Answers 3 answers
  • Subscribers 32 subscribers
  • Views 1952 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.

TM4C1294NCPDT: Programming XDS110 configuration to blank TM4C1294 MCU onboard AWR1243BOOST

James Bonnett
Prodigy 70 points
Part Number: TM4C1294NCPDT
Other Parts Discussed in Thread: AWR1243BOOST, AWR1243, AWR1443, AWR1642,

I have a custom PCB which follows much of the interconnect design of the AWR1243BOOST but with different antenna configurations. The AWR1243BOOST utilizes a TM4C1294NCPTD MCU configured to be an XDS110 emulator for configuration of the AWR1243. The TM4C1294NCPTD on this custom PCB, however, is new and unconfigured. I've reviewed some of the technical documentation for this device and the AWR1243BOOST which this PCB is based on, and it appears there is no external connection available to the MCU JTAG on either design. There is a micro-USB port connected, and the documentation suggests the bootloader should be accessible via USB to load applications via the LM Flash Programmer utility (though I'm also not sure it's reasonable to assume the bootloader is even present as this is a new chip), but I've been unable to configure the device with an appropriate driver so that LMFlash can recognize it. If the bootloader is *not* present, I'm not sure how it's possible to configure the device based on my reading so far... my thinking is there must be SOME way of programming the devices on the board using the interfaces present (otherwise how is TI initializing their AWR1243BOOST devices?), so perhaps there's something I'm missing; does anyone else have experience or ideas on how this can be done?

  • 0
    TI__Guru*** 135355 points

    Hello James,

    So basically what you are trying to do is turn the TM4C into the same emulator that is used on the BoosterPack?

    The TM4C on the BoosterPack is loaded with a specific binary that allows it to emulate an XDS110 in order to allow customers to not need to buy an emulator for basic evaluation. However, as far as I am aware, we do not provide that binary and therefore you would not be able to program a TM4C with that functionality. For custom boards you can either use an existing BosoterPack and jumper over the JTAG connections OR you can purchase an XDS110.

  • 0 in reply to Ralph Jacobi
    Prodigy 70 points

    Thanks for the reply, Ralph.

    Yes, that's exactly what I'm trying to do. Sounds like it might not be possible; I think I'll start with jumpering over from the BoosterPack since I have one of those handy and look into buying an XDS110.

    In the event I can track down the binary, do you think it's possible to program the TM4C with the interfaces I have available, or would I need access to more pins? Is there a driver that would allow LMFlash to recognize the chip?

    Thanks again,

    J

  • 0 in reply to James Bonnett
    Guru 92251 points

    James Bonnett said:
    In the event I can track down the binary, do you think it's possible to program the TM4C with the interfaces I have available, or would I need access to more pins?

    I haven't tried it myself, but the ccs/ccs_base/common/uscif/xds110 directory of a CCS 9 installation contains the XDS110 bootloader and firmware binaries, with instructions for how to flash the binaries.

  • 0 in reply to Chester Gillon
    TI__Guru*** 135355 points

    Hello Chester,

    Thanks, I checked with someone who knows a lot more about what we offer with regards to debuggers and that's correct. Here is a page with more details and instructions: https://software-dl.ti.com/ccs/esd/documents/xdsdebugprobes/emu_xds110.html

    James,

    That said, the AWR1243 shouldn't be supported by the XDS110... are you sure that's what is on the BoosterPack?

    From what I see in the User's Guide:

    "XDS110-based JTAG emulation with serial port, for onboard QSPI flash programming (for AWR1443)"

    It sounds like the XDS110 is only for the AWR1443.

  • 0 in reply to Ralph Jacobi
    Prodigy 70 points

    Ralph,

    I agree that's what it sounds like from the wording, but that's what seems to be there. When connected to my Windows machine via USB, the various ports of the AWR1243 BoosterPack show as 'XDS110 Class' devices (just as in section 3.5 of the user guide). The product page for the AWR1243BOOST also shows "XDS110-based JTAG with serial port interface for flash programming" under features. Perhaps there is some additional QSPI flash capability on the AWR1443 that doesn't exist on the 1243?

    I read through the link you provided and tried some of the troubleshooting procedures, including grounding the JTAG TDO pin (package pin 97) since the pin is reasonably accessible to force the device into DFU mode, but this unsurprisingly had no effect (as I doubt the device comes flashed with a bootloader, but it seemed worthwhile to try). 

    I think the resolution is that I need to somehow breakout the TM4C JTAG interface and use another XDS110 (possibly the one from the BoosterPack) to flash the MCU, or just forego using the MCU and use this method to program the AWR1243.

    Chester,

    Thanks very much! I did some poking around with the instructions in the readme document in that directory - seems like for the xdsdfu application to recognize the device, it needs to somehow show up as an XDS110, which I haven't so far been able to make it do... There's a section at the bottom of the readme for "Recovering a Bricked XDS110 Without JTAG" which seems to contain a lot of the same procedures as the Troubleshooting section in the link Ralph shared. I tried forcing the USB device to use the XDS110 driver, but I can't seem to get it to do so - the issue may be that Windows reports that "Device Descriptor Request Failed" and stops the device "because it has reported problems (Code 43)". Perhaps possible that I could program it if I could get around that, but I'm thinking the only option is to somehow access the TM4C's JTAG interface with another probe.

    Thanks,

    J

  • 0 in reply to James Bonnett
    TI__Guru*** 135355 points

    Hello James,

    If you want, I can see if someone from the AWR team can comment further, I don't have enough understanding of how that BoosterPack was setup to elaborate on the comments in the User's Guide.

  • 0 in reply to Ralph Jacobi
    Prodigy 70 points

    Ralph,

    Thanks, I think that would be helpful - the thing that keeps coming back to my mind is that for these BoosterPacks to be sold (and unless they're either somehow assembled with preconfigured parts or configured with some special jig) then the means to configure the pieces must be here on the board. If somebody from the AWR team would be willing to comment on that, I think that'd be very instructive.

    Thanks,

    J

  • 0 in reply to James Bonnett
    Guru 92251 points

    James Bonnett said:
    I read through the link you provided and tried some of the troubleshooting procedures, including grounding the JTAG TDO pin (package pin 97) since the pin is reasonably accessible to force the device into DFU mode, but this unsurprisingly had no effect (as I doubt the device comes flashed with a bootloader, but it seemed worthwhile to try).

    A TM4C129 device has a bootloader in ROM, and when the user flash is erased (as is the case for a new part) then the ROM bootloader enters DFU mode when connected to the USB port.

    In AWR1642: Custom Board Is Not Detected By USB Comm Port another user was also trying to incorporate an on-board XDS110 on a custom board similar to a AWR1642 BOOST. The referenced thread has the xdsdfu commands to program the XDS110 boot loader and firmware.

    James Bonnett said:
    I tried forcing the USB device to use the XDS110 driver, but I can't seem to get it to do so - the issue may be that Windows reports that "Device Descriptor Request Failed" and stops the device "because it has reported problems (Code 43)".

    What are the PK4 .. PK7 pins on the TM4C1294NCPDT device on your board connected to?

    According to TMDSEMU110-U: GPIO control for embedded XDS110 - prerequisites it appears the XDS110 boot loader / firmware samples PK4 .. PK7 to determine if the XDS110 has a USB connected directly to the TM4C1294NCPDT or via an external USB3300 high-speed USB phy. The exact significance of the strapping on the PK4 .. PK7 pins on the XDS110 boot loader / firmware doesn't appear to be public information.

  • 0 in reply to Chester Gillon
    Prodigy 70 points

    Chester,

    Chester Gillon said:
    A TM4C129 device has a bootloader in ROM, and when the user flash is erased (as is the case for a new part) then the ROM bootloader enters DFU mode when connected to the USB port.

    Thanks, that's excellent news! A colleague of mine was just suggesting this may be the case as well, so I'm hopeful my problem actually just boils down to a Windows interfacing issue. 

    PK4 and PK5 are pulled down to GND with a 1k resistor, PK6 and PK7 are pulled to 3.3V with a 1k resistor. This appears also to be the configuration on the AWR1243BOOST schematics, so hopefully this is an acceptable configuration.

    Thanks,

    J

  • 0 in reply to James Bonnett
    Prodigy 70 points

    I think I've made a bit of progress. It turns out the ESD protection IC for the USB interface was interfering with the USB communication somehow - the schematic seems identical to that of the BoosterPack, so perhaps an error in layout or assembly. With the ESD protection IC removed, Windows recognizes a Stellaris Device Firmware Upgrade device in the Device Manager. I'm able to query it using xdsdfu, and have attempted to load the firmware.bin file per the instructions in the readme, but it doesn't seem to take... the device resets, and then comes right back in DFU mode again. The xdsdfu utility has an option for putting devices into DFU mode, but I'm not sure how to go about getting the device out of DFU mode.

    I'm also able to see the device in LMFlash, and can read back the flash to see that it isn't empty. I tried using this utility to write the firmware.bin file to flash on one of these boards, but the device then went away and so far I can't get it back so I'm reluctant to try that again (perhaps I should have provided an offset? Checking the documentation again).

    Anyhow, if this behavior seems familiar to anyone, I'd welcome any inputs.

    EDIT - After reading through this again: http://dev.ti.com/tirex/explore/node?node=ALFqIj4dX6S.TZRERoSphA__FUz-xrs__LATEST  
    I saw "In case the pod can't be acknowledged by the host or only shows the Stellaris DFU entry on the Control Panel, it means the custom bootloader may be damaged."

    Makes sense - the default bootloader and the custom bootloader must differ. I flashed the custom bootloader with ./xdsdfu.exe -b boot_loader.bin -r (which took a while). The device still returned as Stellaris Device Firmware Upgrade after power cycle and reconnect, so I then reflashed the firmware.bin, cycled power, and reconnected.
    Unfortunately the device is still showing as Stellaris Device Firmware Upgrade... Will retry the bootloader - still seems like that might be the key.

  • 0 in reply to James Bonnett
    TI__Guru 58035 points

    Hello,

    In the device manager are you still see the device listed as "Stellaris Device firmware upgrade" ?

    Can you try giving the "Xdsdfu.exe -b boot_loader.bin –r" followed by the " Xdsdfu.exe -f firmware.bin –r" command?

     

    Regards,

    Vivek

  • 0 in reply to Vivek Dham
    Prodigy 70 points

    Hi Vivek,

    I tried the bootloader flash command again and the device immediately was re-recognized as an xds110! A few slight differences this time - I used an elevated command prompt and added a -v tag for more verbose output; unsure whether either had any appreciable effect. Last time I ran the command, it pretty much just sat there for several minutes and exited without printing anything (thus the verbose tag this time) and I saw pretty much no change from idle in the comms on my o-scope. This time around, it gave me an "are you sure?" prompt and the waveforms showed longer data packets on the USB lines indicating something was indeed happening.

    Looks like this issue is now completely resolved - thank you to everyone who helped me out; hopefully this thread will be helpful to others in the future who find the same problem.

    Thanks,

    J