EK-TM4C1294XL: connecting to the chip using FTDI cable (from pc USB to the chip's UART0)

Thanks. the FTDI cable has one side regular USB connection and the other side 4 wires - VCC, GND, Tx and Rx - all males soldered to the launchpad board the following way:

Vcc (Red) -> 5v

GND (Black) -> GND

Tx (Green) -> PA1 (pin 76)

Rx (White)-> PA0 (pins 74)

what i'm trying to do now is add code to the blinky program make and it send some data every few seconds over UART0. i'm using this cable and coding a client pc application to open the serial com port to read the data - just to make sure that the communication is working over UART0.

when i'm connecting the device with the cable, the device is recognized but with an error - see attached file. is this ok (currently the uploaded design is the original blinky example)?

after installing the driver, i can see the device is ok - "prolific usb to serial". i tried executing "PL2303_CheckChipVersion_v1006.exe" which came with the driver with the correct com port and got a good response:

what i'm trying to do now is program the chip using the flasher tool with blink bin image through UART to make sure that the process works:

when i try "program", i get the following error:

i tried doing this after programming the chip through regular microusb connection with boot_demo1, boot_demo2 and boot_serial examples - none of them worked.

what  am i doing wrong here?

i'm not sure i got it. i did the following (from USB port):

and after that trying to program through UART?

Thanks.

well, i changed the com port to 115200 (it was 9600):

and did the erase again with these settings:

and i'm still getting the error:

however, i believe the communication is ok with the cable since by running the driver test app as i did before (PL2303_CheckChipVersion_v1006.exe) produces a good response:

what do you think?

in addition to the test utility, i programmed the chip with "uart_echo" example and i'm able to receive the bytes i'm sending from my windows app so, the cable seems fine - just the bootloader program isn't working.

ok great. i just tried to use the console flash utility and got the same error:
---------------------------------
c:\ti\TivaWare_C_Series-2.1.3.156\tools\bin>sflash.exe c:\safeshoot\blinky_slow.bin -p 0x4000 -c 7 -b 115200 -d -s 252

Application : c:\safeshoot\blinky_slow.bin
Program Address: 0x4000
COM Port: \\.\COM7
Baud Rate: 115200
Erasing Flash:
Failed to Send Download Command
---------------------------------
i tried it after flash erase after that with "boot_demo1" and after that with "boot_demo2" - same failure with all programs.

The source code for this utility is included so it will help me a lot with my implementations after we solve this issue.

Hi again Ralph.

After finally getting it programmable through UART, i implemented the upload protocol in C# and tried to upload a bin file while debugging the C# side application when boot_serial is programmed into the chip.

i'm not sure that this is the cause, but i cannot upload any more bin files using LM flasher from UART - only from USB which also means i cannot do this from my C# application.

i uploaded the uart_echo program and it is working fine - i am able to receive back the bytes i send through UART, but then after doing the following (previous steps):
entire flash erase
programming the chip with "TivaWare_C_Series-2.1.3.156\examples\boards\ek-tm4c129exl\boot_serial\ccs\Debug\boot_serial.bin"
changing configuration to manual (UART) again with same previous configuration
trying to program "TivaWare_C_Series-2.1.3.156\examples\boards\ek-tm4c129exl\blinky\ccs\Debug\blinky.bin"
i get the same error as before on "Program" button press.

any idea?

another thing i checked:

i can see the following definition for Tx/Rx of uart in "TivaWare_C_Series-2.1.3.156\boot_loader\bl_uart.h"

    //*****************************************************************************
    //
    // This defines the UART receive pin that is being used by the boot loader.
    //
    //*****************************************************************************
    #define UART_RX                 (1 << UART_RXPIN_POS)
    #define UART_RX_PCTL            (UART_RXPIN_PCTL << (4 * UART_RXPIN_POS))

    //*****************************************************************************
    //
    // This defines the UART transmit pin that is being used by the boot loader.
    //
    //*****************************************************************************
    #define UART_TX                 (1 << UART_TXPIN_POS)
    #define UART_TX_PCTL            (UART_TXPIN_PCTL << (4 * UART_TXPIN_POS))

is this right? does it set the PA0 and PA1 pins as Tx/Rx?

BTW - is there a way to debug boot_serial? it doesn't have a "main" and it would be a good thing if i can BP on the UARTSend/UARTReceive calls of the bootloader.

Thanks

Hello Liran,

Regarding the question on bL_uart.h, if you look at the #define list at the top of the file you can see that the UART is mapped to UART0_BASE and Pins A0/A1, so yes that is right.

I haven't debugged the boot loader before, so I am not sure, but as far as putting a BP on those calls you should in theory be able to do that in the bl_packet.c file. The functions SendData, FlushData, and ReceiveData are macro'd to the functions of the boot loader you are using, so for UART those functions will point to:

#ifdef UART_ENABLE_UPDATE
#define SendData                UARTSend
#define FlushData               UARTFlush
#define ReceiveData             UARTReceive
#endif

Regarding why the boot loader issue returned from you, I am afraid I don't have a lot of offer, as it sounds to be an issue with either your order of operations or perhaps some issue with compiling and downloading the code.

Hi Ralph.

i finally found the issue why i couldn't upload through UART after flashing boot_serial.bin - i have to check "Reset MCU after program" to make it work. as i'm coming from arduino world, i didn't know that it doesn't restart at the end of the programming - this problem is finally solved.

however - i have a few questions:

1. when i upload the boot_demo1 by clicking on it and then -> debug, the led starts to blink, but if i disconnect the device's power cables (powering off) and then reconnect them, the led does not blink - why? isn't the program supposed to start the same way on power off/power on?

2. sometimes projects are not becoming active when i click on them, for example - i cannot make boot_demo2 active (see picture 2 to see how i open it and 3 - as it's not becoming active after clicking it) - why is that? if i try to open only the nested boot_demo2/ccs folder it using  "open project from file system" -> it can be made active but it won't compile.

3. i cannot make boot_serial active so i cannot debug it - see picture 1 (i've noticed it has no main.c?).

i've created a fresh new project for the chip and implemented blinky with it to see what project changes i need to make it work and it is working fine. the next step is to add the bootloader code to this project to make it both blink and listen for programming from UART, but i need a working example which i can debug in order to understand what i need to implement in my project.

boot_demo1 is working strange as i described in q1, but even if i try to upload a program after pressing SW1 (right after debug->start) it won't load and present the regular communication error.


Thanks

sorry - attached now:

The behavior of debugging a project vs loading a compiled image with LM flasher seems different:

from Code Composer studio, "blinky" is active -> pressing "Debug" and then "Resume" buttons -> result is that the led starts to blink
power off/power on the chip - the led blinks - this is great.

from LM flasher application:
1. "Reset MCU after program" checked, address 0x0, configuration quick set to TM4C1294XL Launchpad, port: JTAG (uploading through USB)
2. program the device with "c:\Users\Developer\workspace_v7\boot_serial\Debug\boot_serial.bin" (same folder used for the project)
3. program is successful
4. in LM flasher - change to manual configuration (UART setting)
5. select image "c:\Users\Developer\workspace_v7\blinky\Debug\blinky.bin"
6. program address 0x4000, "Reset MCU after program" checked
7. "Program" button -> success.
8. no LED is blinking

i tried power off/on the device and still - no blinking. what can be the reason for that? is 0x4000 the right address to program it?

Many here - about to call for the 'Slaughter Rule' (as thread has expanded  to 3 forum pages - 28 'back-forth') - really hope that ('that did it') proves (at last) true!

Thread's title 'Connecting to the chip using FTDI cable'  -  bears 'LITTLE' relation (to be kind) - to the ever meandering postings - found (near) endlessly - herein...   (at minimum - as Ralph so often does - the thread should have been (properly) CHOPPED - into 'properly Subjected'  -  forum entries.

We're glad that poster has (hopefully) succeeded - yet 'so tired' of seeing  (boring & inaccurate) 'FTDI Cable' - splash across the forum on an (almost) daily basis!

Liran Sorani said:

i suggest you just skip it.

That's a bit difficult to do - as the (errant Subject Line) proves SO LONG - that it overflows into TWO LINES!       Is it REALLY necessary - that we be (endlessly) reminded - that the FTDI cable (flows) - between PC's USB & MCU's UART?    (you CAN edit that Subject Line - reducing its impact...)

BTW - I'm a user-specifier (yet achieve (some) notable  volume device Sales for this vendor) - and believe that any such 'multi-subject thread' borders upon the 'unsearchable' - and 'exhausts those' - who may (otherwise) benefit from SEVERAL of the POINTS WELL MADE - by both YOU - and the vendor...    

(Slaughter Rules exist ... for GOOD REASON!)      And multiple forum users have PM'ed me - requesting some 'relief' - from this ongoing (very slight FTDI involving) thread.     (Have you considered that such repetition (signalling great difficulty/confusion) - may prove UNFAIR - thus  NOT be appreciated - by FTDI?     Should that  fact - NOT enter your consciousness?)

Thank you - FTDI is a long-standing client of (& supplier to) my group. 

Our experience is that their various USB products are clearly, 'TOP CABIN!'         Thus - when their 'brand'  -  so regularly  appears (>30 postings) w/in a 'troubled forum thread' - that 'cannot be good!'    Especially when their product has been proven - by both vendor agent & poster - completely 'blameless!'

I was asked to 'assist' (due to my long history, here) - your cooperation IS much appreciated...