FTDI JTAG

[nicholas99]

I ma having trouble understanding JTAG compatibility with LPCXpresso.

In the past I have worked with LPC1769 using an FTDI FT232H for USB to JTAG. It worked fine in other software which is no longer available. I am working with a very similar system (LPC1768 based) but now am trying to use LPCXpresso and it will not recognize the FT232H as a valid JTAG device. I am (seemingly) able to use it with third party software flasher to upload raw binary data to the chip's flash memory and verify it so I am sure the connection is present.

Currently having 2 issues, one that LPCXpresso will not recognize the FT232H as a JTAG device. Second problem is that I am able to upload binaries to the chip with third party tools, but when I build example projects and output as binary and flash it to memory they do not seem to run - I am aware that example projects are coded for evaluation boards and that port pins may not match up - but even if I change the port/pin to match my board or just use a scope to measure the default pin from the example nothing happens to the pin. Even for example, using the external crystal oscillator which will not oscillate. I've tried blinky, clkout, and a couple of others. Is there something I am missing in regard to uploading raw binary to chip and having the code execute? I'v un-commented the two lines in the build steps to get the *.bin file to be created and then use a utility to flash the bin file starting at memory location 0x0.

[lpcxpresso_supp]

Sorry, LPCXpresso IDE doesn't support generic FTDI FT232H USB -> JTAG convertors. For a list of supported debug probes, please see Which debug probes are supported by LPCXpresso IDE with which MCUs? or the supplied LPCXpresso IDE User Guide. Generally we would recommend the use of the LPC-Link2 (LPC-Link2|NXP ) which provides a cheap but fast debug connection. These are available from many distributors for ~$20.

MCUXpresso IDE (which has replaced LPCXpresso IDE) also adds support for SEGGER and P&E Micro probes, but still won't allow you to debug using your generic FTDI convertor.

With regards to your binaries, you probably haven't set the valid image word :

https://community.nxp.com/thread/389046 

Creating an LPC valid image checksum directly in the image 

Regards,

LPCXpresso Support

[nicholas99]

Thank you for the reply, I had already read the compatible JTAG probe section a dozen times and it is not clear because it says it supports other third party CMSIS probes in a generic way and it was not clear if the FTDI chip was CMSIS compatible or not. I will look into the LPC-LINK2.

On the other hand I cannot get the binaries to work. Your suggestion of the checksum is not likely to be the issue as I have followed the post build instructions which includes the checksum command.

I have investigated further and the crystal oscillator (external) is just flat, it is not oscillating which led me to believe the chip was using the internal RC clock. It seems like many of the example projects use a 12 MHz external clock (which is what I have) so it seems like it should be getting enabled? My board, however, does not have an RTC oscillator instead I connected the pins according to the datasheet for when RTC is not used and set RTCOscRateIn to zero in "board.c" as mentioned in the comments of "chip.h" declaration. Should this be enough to disable the RTC? It just seems as if nothing at all is happening, when I oscilloscope the default blinky output (P0_22) the voltage is 2.3V which is neither low nor high.

[lpcxpresso_supp · Accepted solution]

The MCUXpresso FTDI support is for the legacy Code Red Red Probe and Red Probe+ devices. Once the Code Red emulators reached end of life, we integrated one of the generic FTDI USB to JTAG converters. This project got discontinued due to lack of interest/demand. Generic FTDI offered no solution for ARM Cortex-M parts which supported SWO trace. The FTDI interface at the time had nothing to do with CMSIS, and it's probably still the case. We recommend you purchase one of the external LPC-Link2 probes. With regard to your oscillator problem, upon power-up (or any chip reset), the LPC1768 uses the IRC as the clock source. The other clock sources are typically configured through software.

Thanks and regards,

MCUXpresso Support

[nicholas99]

I will use the LPC-Link2 debugger in the future, but it has not arrived from shipping yet. In the mean time I am still able to use the FTDI chip and a 3rd party application to program raw *.bin files to the chip, and I am able to use LPCXpresso to create the bin files (with checksums) according to the links provided in the initial reply.

However, I seem to be unable to get any of the example projects to function. It seems I am unable to get the LPC1768 to run the firmware after the raw *.bin file has been flashed to the chip. By all accounts it seems as-if the code is not running. The default examples in the LPCOpen projects build ok but the chip does not perform the expected actions. For example, perif_blinky is supposed to toggle P0_22 (pin-56 of LQFP100). On my board this pin is not physically connected to anything, when I scope it the voltage is constant 2.3V which is neither high nor low.

I've also installed MCUXpresso to see if I had different results but they were the same. In creating a default new semi-blank application based on the LPCXpresso 1769 evaluation board (mine uses the 1768 which is the same chip but operates at only 100MHz max). SysInit.c calls Board_SystemInit() which seems to assume a 12MHz external crystal to set a 100MHz clock which is exactly the same crystal I used and the same as my desired clock! The default blank program also includes the following line to enable the LED0 output of the eval board: Board_LED_Set(0, true);

When I build the project, create the bin (and checksum) and then flash the bin to the chip's flash and then re-power the board, nothing happens. The external crystal does not oscillate, and P0_22 is still ~2.3V. 

I am confident that the *.bin file is being programmed to the chip, I can use the utility to write, verify, and erase the flash. I have 2 development prototypes boards and can prove the utility is not giving me false feedback, if I program one board and then swap the boards and perform a verify it fails. So it seems like the code is either not beginning executed or is getting stuck but where it's example code I'm thinking it shouldn't get stuck.

I haven't set any breakpoints, and I'm building release versions since I, for now, don't have a compatible debugger (but I have tested both debug and release builds with the same result). Is there something I am missing to get the code to execute? The only thing I could think of is that my board does not have an RTC oscillator. So I've gone into board.c and changed RTCOscRateIn to zero, and I've also commented out the definition for Debug_Enable in Board.h in case there was any handshaking needed on the UART port that I wasn't doing.

Is there some other special thing I need to do to get the raw binary to execute after flashing?

[lpcxpresso_supp]

It sounds like you have hardware issues to work through. I'm not convinced using the periph_blinky is the correct approach. The LPCOpen projects are built for an evaluation board. If you can't connect a debugger, and your board cannot demonstrate visible I/O, how would you know if code is executing? About all you can do is toggle a pin and probe it with an oscilloscope. I can tell you your chip is working, otherwise the third party tools wouldn't be able to use the on-chip ISP to flash your code.

The IRC referred to earlier is internal to the LPC1768. It's not external to your board. The board setup presumes you have an operational 12 MHz external XTAL. If this XTAL circuit is not working for some reason, you can't expect the board initialization to complete as-is. For the time being, I recommend you do some research and change the clock setup to use the IRC as a clock source. Until your LPC-Link2 arrives, your problem is debugging it.

Thanks and regards,

MCUXpresso Support

[nicholas99]

I appreciate your time in reading and responding. I understand why you would believe there is a hardware issue but I'm not convinced that is the case. As you have said, the fact that I can flash and verify the chip should indicate the chip is working to a point. I've checked, and tripple checked the Vdd, VddA, Vss, VssA, Vbat, VDD_reg, VrefP, VrefN, pins to ensure they are all connected to 3.3V or ground as appropriate. I am using a 12 Mhz xtal with recommended sized caps from the datasheet on the xtal in and out pins, and obviously the JTAG pins out to a connector. Beyond those "critical" things, should is honestly matter how else I have the pins connected on my board? Blinky and other examples were created for an evaluations board but that only determines if an actual LED on P0_22 blinks or not because I don't happen to have an LED on that pin - but I can put my scope on that pin regardless (which is left floating on my board) and still see an output in theory).

Am I missing something to say that it shouldn't matter how the rest of my chip is pinned out so long as I can manually scope the outputs? The default blank project example just seems to enable P0_22 to "ON" and then sit in an infinite  while loop. All my other outputs are either floating, weakly pulled low or weakly pulled high though a 10k resistor to 3.3V, or are fed to data pins of other chips like I2C or UART or CAN transceiver.

Based on my understanding and what I am seeing it seems either that the code is not beginning to execute, or like you said the crystal is not oscillating and the code is stuck initializing, for example waiting for the PLL to lock but it won't or something similar, or there is some other trigger that I forgot about in the initialization routine that I haven't done. As for the crystal, it happens to be the same part I used on my external FTDI USB to JTAG adapter, the same crystal, with the same capacitors, made by the same board house, at the same time - I've tested a couple of those boards and the crystal is oscillating fine so I am hesitant to say the assembly house didn't know how to solder the crystals correctly. I've also checked continuity of the crystal pins to make sure there was no errant solder short and checked several times that each side connects only to the caps and to pins 22 & 23 of the chip. I've also checked the design of the schematic against open source hardware projects which I have used in the past and are known working designs. If there is a hardware issue, and I can't rule it out, but if there is I simply cannot find it at this time.

Do you know if there is an example project which uses the IRC instead of an external chip? It seems all of the LPCOpen projects rely on the same Board_SysInit.c file which sets the crystal as main clock. I am trying to stick to known working example code for now until I can verify the board - I don't want to introduce yet another variable into the mix yet (bugs or bad code) and would rather hold off on custom firmware until I can get past hardware hello world (aka toggle GPIO)

[lpcxpresso_supp]

A few pins do matter. For example, if the ISP (P2.10) pin is left floating at reset, then the part could boot into the ISP and never run user code. This is covered in an LPC FAQ. See Design Considerations for Debug. I didn't meant to suggest your XTAL circuit was broken, I thought you said it was suspect. I can tell you I've designed a board using this part, and I never had trouble with the external XTAL.

I don't believe any of the LPCOpen projects are setup to use the IRC as a clock source. You can try downloading the (non-LPCOpen) legacy projects and possibly find one which uses the IRC (or is easier to modify), but I don't know of one offhand. These are located in your installation at <install>/Examples/Legacy/NXP/LPC1000/LPC17xx. Depending on the LPC17xx archive folder you choose, you'll need to use a compatible CMSIS_CORE library. Good luck.

MCUXpresso Support

[nicholas99]

OK this was it!

Every time the ISP pin was referenced I thought it was the special pin pre-programmed into the example bootloader code that told the bootloader firmware to prepare for UART or USB firmware update, I didn't realize it was the non-user boot code telling the chip not to run any code. I had been using pin P2_10 as a GPIO pin (which is supported according to documentation) to control the wake up status of another chip on the board. That chip has an internal weak pull down (because it's active high) which was making the overall voltage at the pin ~0.6V and must have been keeping the LPC in ISP mode!

I was able to jump P2_10 to 3.3V during boot and guess what, the code runs fine. I'm sad that I misunderstood the purpose of the pin but I'm quite glad to have identified the issue.

[nicholas99]

Addendum

I just cleaned and rebuilt the project after going into Board_SysInit.c and commenting out the line: Chip_SetupXtalClocking() which I think should mean the xtal is never selected and the default IRC oscillator remains being used. After flashing the file to the chip the result was exactly the same nothing as before, all the I/O pins I have tried to measure (including P0_22) are at 2.3V.

I just want to ask this question again, are we sure the *.bin file created by the post build steps is the full executable raw firmware start to finish, and not just the portion of the firmware that is compatible with the example bootloader? Most topics I see with people looking for firmware are using it with a bootloader but in this case I am using an external utility to flash memory starting at location 0x0.Once I get this working later I will eventually be using a bootloader at which point I will then want to ask how to built *.bin files of only the firmware needed after the bootloader :smileyhappy: but thats a problem for later.