hi

i think the problem is in line 6 but not sure what it means ....and last in the screendump you can see that the target halted ...dont now how to start ..

Open On-Chip Debugger 0.9.0-dev-00418-g9afb8b4-dirty (2015-09-28-12:09)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
Info : The selected transport took over low-level target control. The results might differ compared to plain JTAG/SWD
Warn : use ‘stm32l4.cpu’ as target identifier, not ‘0’
adapter_nsrst_delay: 100
srst_only separate srst_nogate srst_open_drain connect_assert_srst
adapter speed: 1800 kHz
srst_only separate srst_nogate srst_open_drain connect_assert_srst
Info : clock speed 1800 kHz
Info : STLINK v2 JTAG v25 API v2 SWIM v13 VID 0x0483 PID 0x374B
Info : using stlink api v2
Info : Target voltage: 3.238973
Info : stm32l4.cpu: hardware has 6 breakpoints, 4 watchpoints
adapter speed: 240 kHz
target state: halted
target halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0x08001220 msp: 0x20020000
Info : Unable to match requested speed 8000 kHz, using 4000 kHz
Info : Unable to match requested speed 8000 kHz, using 4000 kHz
adapter speed: 4000 kHz

• Programming Started **

auto erase enabled
Info : STM32L4xx flash size is 1024kb, base address is 0x8000000
target state: halted
target halted due to breakpoint, current mode: Thread
xPSR: 0x21000000 pc: 0x20000068 msp: 0x20020000
wrote 6144 bytes from file Debug/test_l4_4.elf in 0.312000s (19.231 KiB/s)

• Programming Finished **
• Verify Started **

target state: halted
target halted due to breakpoint, current mode: Thread
xPSR: 0x61000000 pc: 0x2000002e msp: 0x20020000
verified 4920 bytes in 0.328601s (14.622 KiB/s)

• Verified OK **
• Resetting Target **

adapter speed: 240 kHz
shutdown command invoked

Can no one help ??

My other boards stm32F4 and Stm32F429 and Stm32F/ are working with cubeMX and open stm but the STM32L4 do not ...The code i generate in cubeMX for either ewarm or stm work on IAR but not on OPENSTM ...

Where to look after the problem ?

Hjalmar

Run the ST-Link Utility and verify that the target communication mode is set to “Connect Under Reset”. My understanding is that if this option is not set for a L family device then the ST-Link can’t communicate with the target device.

hi ...i already did that......i was on the stm32l4 seminar and there they told me to do.....

other suggestions ?

hjalmar