Binaries created under Windows 10 no longer work with LM Flash Programmer

That doesn't sound like a binary issue. Easy to test. Try copying the binary to another (non-Win10) machine and download.

Robert

Maybe you just need a professional JTAG tool?

Hi Robert,
Thanks for your help again. I have old binaries that I created prior to my Windows 10 upgrade and they load fine. Only the binaries after the upgrade will not load using LM Flash Programmer. I can load the new binaries using a JTAG connector successfully, but LM Flash Programmer allows other engineers without a JTAG connection to download new code. I'm trying to get my hands on a Windows 7 computer right now to see if that makes a difference. But definitely there is some difference between my old binaries and my new ones, as far as LM Flash Programmer is concerned. I'm hoping someone can comment on the specific error I'm getting.
Thanks,
Cindy

Mayyyybeeeee. If they are actually binaries I think it's very unlikely. If they are some other file that includes debuf info then it's just unlikely. They error purports to come from the communication section so the file contents should either have been parsed at this point or will be parsed after.

You can also do a binary compare between the different binaries. Of course that only works if they are actually binary images.

Robert

BTW the engineers w/o a development environment have perhaps a greater requirement for a proper JTAG tool, not a lesser.

Hello Cynthia,

I will try to find a Windows 10 system and try this out.

Thanks,
Sai

Hello Cynthia

Can you check if the USB on the Windows 10 devices are enumerating correctly? I want to make sure it is not the CAT file issue.

Regards
Amit

Hi Amit-

I believe the enumeration is correct given that if the flash is erased, LM Flash Programmer is able to successfully program the micro.  It's only when there is a program in the flash, and I'm using ROM_UpdateUSB on the micro side, that I get the error and failure.

Thanks!

Cindy

I tried downloading the new Win10 created binary from a Win7 (again using LM Flash Programmer) computer and failed...

Hello Cynthia,

Did you compare the binaries generated on Win10 and Win7 and are they the same? Also is the device correctly in DFU mode?

Regards
Amit

Hi Amit-

Yes- I installed the same version of CCS on a Windows 7 computer, copied my project (from the W10 computer), and created the binary.  Turns out the W7 and W10 binaries are identical.  AND they behave the same.  The behavior is actually more complicated than I originally realized.  Here's what I've seen:

- Old binary on micro: all binaries will download via LMFP

- New binary on micro: only old binaries will download.  New ones will cause LMFP to give the 0044 error.

So as long as an old binary is part of the equation, all works as expected.  By "old" I mean binaries created prior to my W10 upgrade (I guess this could be a coincidence).  Since LMFP will erase the micro at the beginning of the programming attempt, once an attempt fails, I can power cycle the micro and use LMFP to successfully program the micro using the Auto Baud Support feature.  All binaries can be successfully programmed using this method.

As far as DFU mode, I'm using ROM_UpdateUART()- is that sufficient to put the device in DFU mode?

Thanks for your help!

Cindy

Hello Cindy

ROM_UpdateUART and DFU are not the same thing. DFU is Device Firmware Upgrade and is a formal specification from USB.org. UART on the other hand is industry-adopted interface (before my time).

Since you are using UART, can you check when the firmware upgrade is attempted, is it correctly configured?

Regards
Amit

Hi Amit:

On the micro side, here is the code I'm using (same for all binaries I've been testing):

void SerialDownload(void)
{

// Stop the watchdog from resetting the system
ROM_WatchdogResetDisable(WATCHDOG0_BASE);

// ATTEMPTING TO BOOT LOAD A BINARY...
// SET THE CLOCK AND UART0- THAT's IT
// The clock of choice!
// Clock of 80MHz- trouble with UART at 80MHz- use separate clock for UART
ROM_SysCtlClockSet(SYSCTL_SYSDIV_2_5|SYSCTL_USE_PLL|SYSCTL_XTAL_16MHZ|SYSCTL_OSC_MAIN);

// Bootloader
ROM_SysTickIntDisable();
ROM_SysTickDisable();

// Disable all processor interrupts. Instead of disabling them
// one at a time, a direct write to NVIC is done to disable all
// peripheral interrupts.
//
HWREG(NVIC_DIS0) = 0xffffffff;
HWREG(NVIC_DIS1) = 0xffffffff;
HWREG(NVIC_DIS2) = 0xffffffff;
HWREG(NVIC_DIS3) = 0xffffffff;
HWREG(NVIC_DIS4) = 0xffffffff;

// Setup UART0
ROM_SysCtlPeripheralEnable(SYSCTL_PERIPH_UART0);
ROM_SysCtlPeripheralEnable(SYSCTL_PERIPH_GPIOA);

//
// Enable pin PA0 for UART0 U0RX
// RS-232 Header, Port 0, Receive
// RXD-TM4-V33-1
ROM_GPIOPinConfigure(GPIO_PA0_U0RX);
ROM_GPIOPinTypeUART(GPIO_PORTA_BASE, GPIO_PIN_0);

//
// Enable pin PA1 for UART0 U0TX
// RS-232 Header, Port 0, Transmit
// TXD-TM4-V33-1
ROM_GPIOPinConfigure(GPIO_PA1_U0TX);
ROM_GPIOPinTypeUART(GPIO_PORTA_BASE, GPIO_PIN_1);

// Use the PIOSC clock to clock the UARTS- reliable and safe clock
// Set for normal terminal functioning
ROM_UARTClockSourceSet(UART0_BASE,UART_CLOCK_PIOSC);

// 8 data bits, 1 stop bit, 460800 baud, no parity
ROM_UARTConfigSetExpClk(UART0_BASE, PIOSC_CLK_RATE, 460800,(UART_CONFIG_WLEN_8 |
UART_CONFIG_STOP_ONE | UART_CONFIG_PAR_NONE));

// Wait for a firmware update over the UART- we won't come back from this...
ROM_UpdateUART();

return;
}

On the LMFP side I Use Manual Configuration: Disable Auto Baud Support and set the Baud Rate to 460800 and Transfer size to 252.

Thanks,
Cindy

Hello Cindy

Can you try the update mechanism with UART Clock Source as System clock or by reducing the UART baud rate to something like 115200 bps?

Regards
Amit

Hi,
I had tried lowering the baud rate already, but I repeated the test using System clock at 115200 and then PIOSC at 115200- both tests failed in the same fashion (successful if an old binary is part of the equation, failed with two new binaries).
Cindy

Hi Amit,

I created a small project that sets the system clock and blinks a light. The .bin from this project can be successfully downloaded with LMFP regardless of what binary is executing in the micro. So the problem is NOT directly connected to the W10 upgrade- or if it is, it is a subtle connection. I set a break point in one of the offending binaries to make sure that ROM_UpdateUART() is getting called as expected, and it is (kind of obvious since sometimes binaries are getting downloaded successfully).

So the question remains as to why LMFP will at times find some sort of conflict between the binary in the micro and the binary it's trying to download. And this conflict is repeatable with a given set of binaries.

Thanks again,
Cindy

Hello Cindy

That is hard to tell without having the same setup as yours. There is an application note on serial boot loaders which can be used to re-construct the UART transaction to see what is happening. It is some tough manual work with a scope/LA, but it is surely going to help reconstruct the point of failure.

www.ti.com/.../spma074a.pdf

Regards
Amit

Hi Amit, 

Thank you for the suggestion.  Before I consider heading down that path, can you please tell me what the failure 0044 means?  That might help me determine if finding the point of failure is likely to lead to a solution.

Thanks,

Cindy

Hello Cynthia

There are multiple causes associated with 0044 (and unfortunately it is not documented well).

Regards
Amit

Hi Amit,

I think I know the source of the problem, though I don't understand WHY it's a problem.  The common thread among all the binaries that aren't loading properly is that they have code placed at absolute addresses, causing blank spaces within the binary (that are all zeros when examined with a hex editor).   Would this cause a problem with LMFP or with ROM_UpdateUART?  I'll try to send you a private message with one of the offending binaries attached.

Thanks,

Cindy

Hello Cindy

That should not be an issue, since the LMFlashProgrammer only reads a binary and programs it. It does not matter if the values are 0x0 or 0xFFFFFFFF.

Regards
Amit

What could be an issue in that case is that the binaries are padded.

Robert

Hello Robert,

Longer download time would be the direct impact if padding is done to fill the 1MB region.

Regards
Amit

Hi Amit-

As Robert pointed out, the problem could be associated with length- the padded binaries are almost twice the size as the unpadded.

Could I privately send you one of the binaries in question- would that be a help? I know you couldn't run it, but you could see it and test it with LM Flash Programmer.

Thanks,
Cindy

Hello Cindy

You may send me the binary and I can try to download it on an EK-TM4C129XL connected launchpad to see if it downloads with or without issue.

Regards
Amit

Hey Amit-
Thank you for the offer. I tried sending you a private message, attaching the binary, and the message was rejected (possibly due to size or format?). Is there another way to get it to you?
Thanks,
Cindy

Hello Cynthia,

Rename the file extension nib and then zip it and attach.

Regards
Amit

Amit- Success. Let me know if you don't receive it.
Thanks! Cindy

Hello Cindy

I downloaded it on the EK-TM4C1294XL with the Serial Port, Baud rate 460800 bps, transfer size of 252 and "Disable Auto baud support" check box cleared. Since I am not sure how to put it back in Boot Loader mode, please advise.

Regards
Amit