STM32L051R8 Program Issue with Cube Programmer

[CTerr.1]

I am working with the L051 chip and having issues with the CubeProgrammer Download..
History:   we work with many of the STM32 chips.....and have for years, so well versed in this ...
so this is an issue that we have not seen using any of the Tools...

I wrote a test program, very simple toggle led....
Set up the .IOC with Freertos
Program compiles just fine... as expected.....

But this program is not the issue, using the Cube programmer is where the error comes in..

Hardware setup....
Custom board with STM32L051 chip.
Using an FTDI USB  - TTL cable for programming PORTA
100K pullups on the TX and RX as per AN2606
BOOT1 pin pulled low, via 10K resistor for correct Boot config.

Issues:
We are able to connect to the chip in CubePrgmr just fine every time...
In the TAB   Erasing and Programming:
we load the   .ELF   file in to the prgmr and try to 'START PROGRAMMING'
the download starts then:   See below:::

10:41:02 : Memory Programming ...
10:41:02 : Opening and parsing file: STM32L051R8T_Test.elf
10:41:02 : File : STM32L051R8T_Test.elf
10:41:02 : Size : 13.92 KB
10:41:02 : Address : 0x08000000
10:41:02 : Erasing memory corresponding to segment 0:
10:41:02 : Erasing internal memory sectors [0 111]
10:41:02 : Download in Progress:
10:41:03 : Response received from device: NACK
10:41:03 : Error: Write address not acknowledged: 0x8000900
10:41:03 : Error: failed to download Segment[0]
10:41:03 : Error: failed to download the File

Note:  at different times the  Address: 0x................  will vary....

I'd decreased the BAUD connection rate to 19200  but still get these errors...

There are times that if manages to program ok  , but they are few... maybe 1 out of 20 times...

NOTE:  
this is the same board we had used with an STM32L162 chip and had no issues whatsoever...
It was just when we switched to the L051 that the connectivity seems to have gone bad....

I've tried different USB ports, even different computers with the same issue...
So after a week of working this issues....I've have no real solution or even an idea to start looking for one.

As a last resort have even back peddled to an earllier version of Cube Programmer,  same issue...
so from an investigative POV,  it is looking like the L051 chip has some difference I am over looking.

BUT.....I would love to hear from the expert folks to see what you have to offer..

Thanks in advance

Chuck

[MM..1]

Why you dont use SWD? And 100k pull for what?

AN2606 say use one of 

and init Pattern 1 (described in Table 2). Table 127 

show your schematics

[CTerr.1]

As mentioned the design is done.....

see page 39 AN2606 recommendations

regards..

[CTerr.1]

Just a quick add on,....

The board uses USART1 so the firmware can be easily updated in the field without extra equip...

[CTerr.1]

Also.... BOOT0   BOOT1 are strapped correctly, as this is a mature design, just the  uP has changed

from the L162  to  L051

[MM..1]

You waste time, show schematics L051. 

[CTerr.1 · Accepted solution]

Progress...     after using a few different FTDI ->TTL cables the issue could be resolved.

Altho with the same board and the 162 chip installed , ALL the cables worked fine.
Again board design mature, 5yr product using 162 with no issues...   pretty simple design..

Tested on 25each  051 / 162 boards results were .... all the 162 chip boards programmed perfectly

while the 051 chip boards had various program download fail attemtps..  
Again....but only when downloading,  never an issue when bootload CONNECTING, which we all know are the simple

handshake communications.

Seems the 051 program loader is more sensitive to timing than the later 162 chip....

NOTE:  both TX and RX signals on the scope for the 162 met  EIA/TIA-232-E standard requirements ..

the TX on the 051 boards had a small jitter,  Nothing outside the spec, but we have to conclude

that there is a diff between these two chip bootloaders, which seems strange as most of the STM family chips

share the same architecture design.

We could possible have a batch of  051  chips that show this issue.
We have ordered another 500 pcs of the 051 from a different vendor to help avoid same batch buy and
Will perform these same tests hopefully with better results..

Closing this out.....