stm32L476 and chip_id

[pb7]

I think there is a bug in devices.xml file for the STM32L476 device

65027 - Info: "ST Link V2 / Nucleo found!" 65027 - Info: "Fetching version..." 65027 - Info: "Changing mode to SWD..." 65127 - Info: "Fetching mode..." 65128 - Info: "Mode: Debug" 65128 - Info: "Fetching status..." 65128 - Info: "Status: Core Halted" 65128 - Info: "Fetching MCU Info..." 65128 - Info: CoreID: "2ba01477" 65129 - Info: CM3/4 Searching at E0042000 65129 - Info: ChipID: 0x415 65129 - Error: Did not find chipID! 65129 - Info: "Device not found in database!" 65129 - Error: Device not found in database! 65129 - Info: "Disconnecting..." 65130 - Info: "Disconnected."

There might be something else wrong also... I get this:

Flash size: 25621KB. Should be 1MB

ps. I just got this board and I have no experience with STM ;)

[fpoussin]

L4 are not supported yet, they probably have a different flash memory size register which I need to specify. I'll have a look.

[fpoussin]

Actually there was a typo in devices.xml, it should work now.

[fpoussin]

The ChipID should be found now. I also updated the registers for the flash size and controller.

[pb7]

Hi,

Thanks,

I have been using st-link with the simple change for the device id. Its been working fine for me.

I will grab the latest version in a few days.

Thanks for the fix.

-pb

On 11/10/15 19:10, Fabien Poussin wrote:

The ChipID should be found now. I also updated the registers for the flash size and controller.

— Reply to this email directly or view it on GitHub https://github.com/fpoussin/QStlink2/issues/16#issuecomment-155609180.

[fpoussin]

Did you test the fix?

[pb7]

Hi,

Seems to work fine. I can erase and program flash. I can connect via gdb.

$ st-util

2015-11-17T15:15:54 INFO src/stlink-common.c: Loading device parameters.... 2015-11-17T15:15:54 INFO src/stlink-common.c: Device connected is: L4 device,id 0x10076415 2015-11-17T15:15:54 INFO src/stlink-common.c: SRAM size: 0x18000 bytes (96 KiB), Flash: 0x100000 bytes (1024 KiB) in pages of 2048 bytes 2015-11-17T15:15:54 INFO gdbserver/gdb-server.c: Chip ID is 00000415, Core IDis 2ba01477. 2015-11-17T15:15:54 INFO gdbserver/gdb-server.c: Target voltage is 3269 mV. 2015-11-17T15:15:54 INFO gdbserver/gdb-server.c: Listening at *:4242... 2015-11-17T15:16:43 INFO gdbserver/gdb-server.c: Found 6 hw breakpoint registers 2015-11-17T15:16:43 INFO gdbserver/gdb-server.c: GDB connected.

st-flash write ./build/ch.bin 0x8000000 2015-11-17T15:15:37 INFO src/stlink-common.c: Loading device parameters.... 2015-11-17T15:15:37 INFO src/stlink-common.c: Device connected is: L4 device, id 0x10076415 2015-11-17T15:15:37 INFO src/stlink-common.c: SRAM size: 0x18000 bytes (96 KiB), Flash: 0x100000 bytes (1024 KiB) in pages of 2048 bytes 2015-11-17T15:15:37 INFO src/stlink-common.c: Attempting to write 29064 (0x7188) bytes to stm32 address: 134217728 (0x8000000) Flash page at addr: 0x08007000 erased 2015-11-17T15:15:37 INFO src/stlink-common.c: Finished erasing 15 pages of 2048 (0x800) bytes 2015-11-17T15:15:37 INFO src/stlink-common.c: Starting Flash write for F2/F4/L4 2015-11-17T15:15:37 INFO src/stlink-common.c: Successfully loaded flash loader in sram size: 29064 2015-11-17T15:15:38 INFO src/stlink-common.c: Starting verification of write complete 2015-11-17T15:15:38 INFO src/stlink-common.c: Flash written and verified! jolly good!

./st-info --flash 0x100000

./st-info --sram 0x18000

./st-info --descr L4 device

./st-info --pagesize 0x800

./st-info --chipid 0x0415

I have no test plan to follow but all seems fine. I can connect via gdb and so the usual things..

-pb

On 11/17/15 10:33, Fabien Poussin wrote:

Did you test the fix?

— Reply to this email directly or view it on GitHub https://github.com/fpoussin/QStlink2/issues/16#issuecomment-157404879.

[fpoussin]

You have to test with qstlink2, not st-link which is a totally different program.

[pb7]

Hi Fabien,

Oops.. My bad.

qstlink2:

Version 1.2.1

"connect command;

146886 - Info: "Searching Device..." 146886 - Warning: Cannot open device 146911 - Info: "ST Link V2 / Nucleo found!" 146911 - Info: "Fetching version..." 146912 - Info: "Changing mode to SWD..." 147012 - Info: "Fetching mode..." 147012 - Info: "Mode: Debug" 147012 - Info: "Fetching status..." 147013 - Info: "Status: Core Running" 147013 - Info: "Fetching MCU Info..." 147013 - Info: CoreID: "2ba01477" 147014 - Info: CM3/4 Searching at E0042000 147014 - Info: ChipID: 0x415 147014 - Info: Device type: "STM32L4xx" 147014 - Info: Flash size: 1024 KB

MCU Type: STM32L4xx Flash base: 0x8000000 Chip ID: 0x415 Flash Size: 1024KB

I can receive a file and then perform a verify that passes.

I'm having a problem programming (sending) the device. It seems to start the transfer but it sure takes a long time (longer than I'm willing to wait).

14914 - Info: CM3/4 Searching at E0042000 14914 - Info: ChipID: 0x415 14914 - Info: Device type: "STM32L4xx" 14914 - Info: Flash size: 1024 KB 38661 - Info: "Size: 28KB" 40241 - Info: "Sending /home/phb/stm32_devel/chibios-svn-8509-trunk/demos/STM32/RT-STM32L476RG-NUCLEO/build/ch.bin" 40242 - Info: Using loader 40252 - Info: Writing from 08000000 to 08007180 40280 - Info: Loader ":/bin/loader_l1.bin" 40283 - Warning: Data is not 32 bit aligned! Padding with 2 Bytes 40285 - Info: "Loader uploaded"

and then the led on the board is flashing...

"Writing" on the "Transfer Progress" is filled in; Says "Transfered 0/4944KB" and the progress bar is 0%.

I have waited for several minutes.

The file is chibios:

ls -al

29056 Nov 18 20:34 ch.bin

As a test I will use st-flash...

2015-11-18T20:39:37 INFO src/stlink-common.c: Loading device parameters.... 2015-11-18T20:39:37 INFO src/stlink-common.c: Device connected is: L4 device, id 0x10076415 2015-11-18T20:39:37 INFO src/stlink-common.c: SRAM size: 0x18000 bytes (96 KiB), Flash: 0x100000 bytes (1024 KiB) in pages of 2048 bytes Mass erasing

---- reset---

st-flash write ./build/ch.bin 0x8000000 2015-11-18T20:39:59 INFO src/stlink-common.c: Loading device parameters.... 2015-11-18T20:39:59 INFO src/stlink-common.c: Device connected is: L4 device, id 0x10076415 2015-11-18T20:39:59 INFO src/stlink-common.c: SRAM size: 0x18000 bytes (96 KiB), Flash: 0x100000 bytes (1024 KiB) in pages of 2048 bytes 2015-11-18T20:39:59 INFO src/stlink-common.c: Attempting to write 29056 (0x7180) bytes to stm32 address: 134217728 (0x8000000) Flash page at addr: 0x08007000 erased 2015-11-18T20:39:59 INFO src/stlink-common.c: Finished erasing 15 pages of 2048 (0x800) bytes 2015-11-18T20:39:59 INFO src/stlink-common.c: Starting Flash write for F2/F4/L4 2015-11-18T20:39:59 INFO src/stlink-common.c: Successfully loaded flash loader in sram size: 29056 2015-11-18T20:40:00 INFO src/stlink-common.c: Starting verification of write complete 2015-11-18T20:40:00 INFO src/stlink-common.c: Flash written and verified! jolly good!

--- and the green led blinks ----

On 11/17/15 15:29, Fabien Poussin wrote:

You have to test with qstlink2, not st-link which is a totally different program.

— Reply to this email directly or view it on GitHub https://github.com/fpoussin/QStlink2/issues/16#issuecomment-157497450.

[fpoussin]

Seems like I am not using the right loader. I'll fix that.

[fpoussin]

It should work now :)

[pb7]

Hi,

Um.. no. Still has the same problem.

./qstlink2 Verbose level: 3 128 - Warning: libpng warning: iCCP: known incorrect sRGB profile 139 - Info: Could not open the devices.xml file. Using internal data. 139 - Info: Devices list loaded. 143 - Info: "32 Device descriptions loaded." 2321 - Info: "Searching Device..." 2321 - Warning: Cannot open device 2346 - Info: "ST Link V2 / Nucleo found!" 2346 - Info: "Fetching version..." 2347 - Info: "Changing mode to SWD..." 2447 - Info: "Fetching mode..." 2447 - Info: "Mode: Debug" 2447 - Info: "Fetching status..." 2448 - Info: "Status: Core Running" 2448 - Info: "Fetching MCU Info..." 2448 - Info: CoreID: "2ba01477" 2449 - Info: CM3/4 Searching at E0042000 2449 - Info: ChipID: 0x415 2449 - Info: Device type: "STM32L4xx" 2449 - Info: Flash size: 1024 KB 92228 - Info: "Size: 28KB" 95877 - Info: "Sending /home/phb/stm32_devel/chibios-svn-8509-trunk/demos/STM32/RT-STM32L476RG-NUCLEO/build/ch.bin" 95879 - Info: Using loader 95888 - Info: Writing from 08000000 to 08007178 95917 - Info: Loader ":/bin/loader_f4.bin" 95922 - Info: "Loader uploaded" 167316 - Info: Transfer done 167317 - Info: "Transfer done" 276673 - Info: "Transfer Aborted" 276674 - Info: "Disconnecting..." 276674 - Info: "Disconnected."

The code is spinning in this log (from this command ./qstlink2 -v) This was from trying to send/program a file called ch.bin.

68947 - Debug: Received: 80:00 68947 - Debug: _[ quint32 stlinkv2::getLoaderPos() ] 68947 - Debug: **[ qint32 stlinkv2::readMem32(QByteArray, quint32, quint16) ]* "Reading at 200007DC" 68947 - Debug: [ virtual qint32 QUsbDevice::write(const QByteArray, quint32) ]* 68947 - Debug: Sending 8 bytes: "FFFFFFF2:07:FFFFFFDC:07:00:20:04:00" 68947 - Debug: [ virtual qint32 QUsbDevice::read(QByteArray, quint32) ]* 68947 - Debug: Received: 00:00:00:00 68967 - Debug: [ quint8 stlinkv2::getStatus() ]_ 68967 - Debug: [ virtual qint32 QUsbDevice::write(const QByteArray, quint32) ]* 68967 - Debug: Sending 3 bytes: "FFFFFFF2:01:00" 68967 - Debug: *[ virtual qint32 QUsbDevice::read(QByteArray, quint32) ] 68967 - Debug: Received: 80:00 68967 - Debug: _[ quint32 stlinkv2::getLoaderPos() ] 68967 - Debug: **[ qint32 stlinkv2::readMem32(QByteArray, quint32, quint16) ]* "Reading at 200007DC" 68967 - Debug: [ virtual qint32 QUsbDevice::write(const QByteArray, quint32) ]* 68967 - Debug: Sending 8 bytes: "FFFFFFF2:07:FFFFFFDC:07:00:20:04:00" 68967 - Debug: [ virtual qint32 QUsbDevice::read(QByteArray, quint32) ]* 68967 - Debug: Received: 00:00:00:00 68987 - Debug: [ quint8 stlinkv2::getStatus() ]_ 68988 - Debug: [ virtual qint32 QUsbDevice::write(const QByteArray, quint32) ]* 68988 - Debug: Sending 3 bytes: "FFFFFFF2:01:00" 68988 - Debug: *[ virtual qint32 QUsbDevice::read(QByteArray, quint32) ] 68988 - Debug: Received: 80:00 68988 - Debug: _[ quint32 stlinkv2::getLoaderPos() ] 68988 - Debug: **[ qint32 stlinkv2::readMem32(QByteArray, quint32, quint16) ]* "Reading at 200007DC" 68988 - Debug: [ virtual qint32 QUsbDevice::write(const QByteArray, quint32) ]* 68988 - Debug: Sending 8 bytes: "FFFFFFF2:07:FFFFFFDC:07:00:20:04:00" 68988 - Debug: [ virtual qint32 QUsbDevice::read(QByteArray_, quint32) ]*** 68988 - Debug: Received: 00:00:00:00 ^C

This is another minor problem.

./qstlink2 --help

"\n\nThis application can be used through the GUI or via the command line. (CLI) \n\nCommand line usage: \nqstlink2 [-hqvcwreV] [path]\n\n-h, --help: shows this help\n-q, --quiet: Quiet output (Nothing) \n-v, --verbose: Verbose output (Debug) \n-c,--cli: Enable command line mode \n-w,--write: Enable write mode - Needs Path \n-r,--read: Enable read mode - Needs Path \n-e,--erase: Flash will be completely erased \n-V, --verify: When used with write, the file will be verified against flash \n-R, --reset: will reset the MCU \n\nExample to write and verify the device: \nqstlink2 -cwV file.bin\nor \nqstlink2 --cli --write --verify file.bin \n\nMore info here\n\n\n" Version: 1.2.1

-pb

On 11/19/15 06:19, Fabien Poussin wrote:

It should work now :)

— Reply to this email directly or view it on GitHub https://github.com/fpoussin/QStlink2/issues/16#issuecomment-158026792.

[fpoussin]

Seems like I'll need to make a new loader.

I don't have an L4 board yet so it will have to wait.

[asez73]

Hi @fpoussin,

So I found https://github.com/texane/stlink/issues/352 which shows that I have to upgrade from windows before trying anything else.

I tried my self compiled download of this repository and connected to an all brand new STM32L476 Discovery board under Ubuntu 14.04 LTS.

Apparently, the board's core is not reckognised by QStlink2, as shown below:

qstlink2
Verbose level: 3
Version: 1.2.2
3601 - Info: Devices list loaded.
3603 - Info: "32 Device descriptions loaded." 
9558 - Info: "Searching Device..." 
9558 - Info: Cannot open device 
9584 - Info: "ST Link V2 / Nucleo found!" 
9584 - Info: "Fetching version..." 
9586 - Info: "Changing mode to SWD..." 
9687 - Info: "Fetching mode..." 
9688 - Info: "Mode: Debug" 
9688 - Info: "Fetching status..." 
9689 - Info: "Status: Core Running" 
9689 - Info: "Fetching MCU Info..." 
9690 - Info: CoreID: 000
9690 - Error: Did not find chipID!
9691 - Info: "Device not found in database!" 
9691 - Error: Device not found in database!
9691 - Info: "Disconnecting..." 
9692 - Info: "Disconnected." 
22045 - Info: "Transfer Aborted" 

Actually, I just wanted to upgrade the boot loader which is a V9.0 as described on ST.com. It is a requirement in order to have a reliable flashing capability.

Do you have any idea about this problem? Thank's for reading.

[fpoussin]

9690 - Info: CoreID: 000

There is something going on here... Does it work under windows or using any other tool?

[asez73]

So, i just edited my post above and i am now rebooting windows... I'll keep you informed

[asez73]

So, after upgrade of the boot loader, everything works on Windows 10: I could get all the idents and so on, and also download a copy of the demo binary stored in the board. A verify of the resulting file and board flash showed no differences.

However, half an hour later, it doesn't work anymore while still running Windows... I think I did not applied the workarounds correctly: they seem to be excluding one-another.

So basically, I think it's not a QStLink2 problem.

[fpoussin]

Ok let me know if you can get it woking.

[creatron]

I tried the 'Latest commit Oct 12, 2016 version on a Nucleo L476 board. All operational but the device does not program. Get 33 Device descriptions loaded. Searching Device... ST Link V2 / Nucleo found! Fetching version... Changing mode to SWD... Fetching mode... Mode: Debug Fetching status... Status: Core Running Fetching MCU Info... Sending /home/yyyk/QStlink2/xxx.bin Loader uploaded Loader settings OK Unlock failed Loader uploaded Loader settings OK. The same program was used with F151 and F03x and works perfectly. I also can read the device, and verify the device. I use Opensuse Leap 42.2 (64Bit)