stm32L476 and chip_id #16

pb7 · 2015-11-04T00:41:55Z

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 · 2015-11-10T23:45:50Z

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 · 2015-11-10T23:59:50Z

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

fpoussin · 2015-11-11T00:10:57Z

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

pb7 · 2015-11-11T03:19:45Z

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
#16 (comment).

fpoussin · 2015-11-17T15:33:45Z

Did you test the fix?

pb7 · 2015-11-17T20:27:10Z

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
#16 (comment).

fpoussin · 2015-11-17T20:29:25Z

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

pb7 · 2015-11-19T01:43:21Z

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
#16 (comment).

fpoussin · 2015-11-19T10:41:12Z

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

fpoussin · 2015-11-19T11:19:50Z

It should work now :)

pb7 · 2015-11-20T05:18:35Z

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
#16 (comment).

fpoussin · 2015-11-20T10:00:14Z

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 · 2016-01-14T15:22:12Z

Hi @fpoussin,

So I found stlink-org/stlink#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 · 2016-01-14T15:33:27Z

9690 - Info: CoreID: 000

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

asez73 · 2016-01-14T15:36:49Z

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

asez73 · 2016-01-14T18:24:04Z

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 · 2016-01-15T14:54:08Z

Ok let me know if you can get it woking.

creatron · 2017-01-11T19:40:19Z

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)

fpoussin added the enhancement label Nov 10, 2015

fpoussin self-assigned this Nov 10, 2015

fpoussin added this to the 1.2.1 milestone Nov 30, 2015

fpoussin closed this as completed Apr 27, 2016

fpoussin mentioned this issue May 25, 2016

MCU Info Device not found in database #26

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

stm32L476 and chip_id #16

stm32L476 and chip_id #16

pb7 commented Nov 4, 2015

fpoussin commented Nov 10, 2015

fpoussin commented Nov 10, 2015

fpoussin commented Nov 11, 2015

pb7 commented Nov 11, 2015

fpoussin commented Nov 17, 2015

pb7 commented Nov 17, 2015

fpoussin commented Nov 17, 2015

pb7 commented Nov 19, 2015

fpoussin commented Nov 19, 2015

fpoussin commented Nov 19, 2015

pb7 commented Nov 20, 2015

fpoussin commented Nov 20, 2015

asez73 commented Jan 14, 2016

fpoussin commented Jan 14, 2016

asez73 commented Jan 14, 2016

asez73 commented Jan 14, 2016

fpoussin commented Jan 15, 2016

creatron commented Jan 11, 2017

stm32L476 and chip_id #16

stm32L476 and chip_id #16

Comments

pb7 commented Nov 4, 2015

fpoussin commented Nov 10, 2015

fpoussin commented Nov 10, 2015

fpoussin commented Nov 11, 2015

pb7 commented Nov 11, 2015

fpoussin commented Nov 17, 2015

pb7 commented Nov 17, 2015

fpoussin commented Nov 17, 2015

pb7 commented Nov 19, 2015

fpoussin commented Nov 19, 2015

fpoussin commented Nov 19, 2015

pb7 commented Nov 20, 2015

fpoussin commented Nov 20, 2015

asez73 commented Jan 14, 2016

fpoussin commented Jan 14, 2016

asez73 commented Jan 14, 2016

asez73 commented Jan 14, 2016

fpoussin commented Jan 15, 2016

creatron commented Jan 11, 2017