Monday, December 11th 2017, 11:57pm UTC+1

You are not logged in.

  • Login
  • Register

Date of registration: Nov 1st 2017

Posts: 9

1

Thursday, November 2nd 2017, 7:35pm

Cant connect to NUCLEO-H743ZI using JLink firmware on the OB ST-Link

Hello,

I used STLinkReflash_170807 to reflush the OB ST-Link with JLink firmware. The process looks successful , but when i try to connect to the board using AC6 IDE, i get a message saying the board is not connected.

Has anyone tried this procedure with NUCLEO-H743ZI, i read that reflushing works great for people, but this is a new product by ST, so not a lot of stuff on the web yet....

Thanks,
Evgeny

SEGGER - Niklas

Super Moderator

Date of registration: Oct 6th 2014

Posts: 1,691

2

Friday, November 3rd 2017, 9:52am

Hi Evgeny,


a NUCLEO-H743ZI board is on its way to us, but will not arrive before the end of next week.
Once we get our hands on it, we will give it a try.


In the mean time, could you give J-Link Commander a try and post a screenshot of its output?

Best regards,
Niklas
Would you like to be added to the J-Link software update notification list, so you get informed automatically when a new version becomes available?
Just write me a PM or in case you want to subscribe to it yourself, please use this link: Link
Notification for J-Link, J-Link Debugger, SystemView & J-Scope: Link
Notification for Embedded Studio: Link

Date of registration: Nov 1st 2017

Posts: 9

3

Friday, November 3rd 2017, 8:25pm

Hi Niklas,

Here it is.....

Thanks,
Evgeny
evgeny_erlihman has attached the following image:
  • jlink_on_stlink.jpg

SEGGER - Nino

Super Moderator

Date of registration: Jan 2nd 2017

Posts: 437

4

Tuesday, November 7th 2017, 1:56pm

Hi Evgeny,

Niklas asked me to take over.
I just tried to connect to a STM32H743I-EVAL board with a regular J-Link Plus probe and had no issues whatsoever.
The Nucleo Board is still on its way so i will test it once it arrives.
In the meantime do you have an external J-Link debug probe that you could try out?

Best regards,
Nino

Date of registration: Nov 1st 2017

Posts: 9

5

Tuesday, November 7th 2017, 3:07pm

Hi Nino,

I do have an Ultra+ probe, i have succeeded loading the firmware to the board using it, but it seems as it disconnects from the board a short time after. Same code runs without disconnecting with OB ST-Link.
The thing is that the Nucleo board does not have a dedicated JTAG/SWO socket for external probes. So after reading ST's document and searching the ST forum, i had to remove two solder bridges - SB110, SB111, and connect the probe to the board using several single wire straps.

Jlink NUCLEO-H743ZI
pin1 CN8 - 3v3
pin4 CN6 - pin3 == GND
pin7 CN4 - pin4 == SWDIO
pin9 CN4 - pin2 == SWCLK
pin15 CN8 - NRST

This is why i was hoping to get use JLink over ST-Link, to eliminate user error in modifying/connecting the board.

Thanks,
Evgeny

SEGGER - Nino

Super Moderator

Date of registration: Jan 2nd 2017

Posts: 437

6

Thursday, November 9th 2017, 6:00pm

Hello Evgeny,

We just received a brand new Nucleo-H743ZI.
I reflashed the ST-Link with the same utility you have used and was able to connect to the target device without any issues (screenshot attached).
Did you change any default jumper settings when using the OB?

Quoted

I do have an Ultra+ probe, i have succeeded loading the firmware to the board using it, but it seems as it disconnects from the board a short time after.

The disconnecting is rather odd. Can you try and erase the target device memory and try to connect to the target with the OB?
Could you try reflash the ST-Link FW and then again the J-Link OB FW?
Do you have another eval board to try? Yours might be in some way defective.

Best regards,
Nino
SEGGER - Nino has attached the following image:
  • Capture.PNG

Date of registration: Nov 1st 2017

Posts: 9

7

Friday, November 10th 2017, 2:57pm

Hi Nino,

It looks like this issue has something to do with the IDE or application code. I reflashed the board by reverting back to STLink firmware, and using the STM32 ST-Link utility erased the flash, updated it back to JLink and connected using J-Link Commander without any issues.

Tried running my code again using the AC6 IDE, and got the board into the same problematic mode. Completely reproducible every time i try. Tried the same code with TrueStudio, and it worked well. This was all done using the OB STLink/JLink.
So i will do some more investigation on what is causing the OB to malfunction.


Thanks,
Evgeny

Date of registration: Nov 1st 2017

Posts: 9

8

Tuesday, November 14th 2017, 3:34pm

Hello,

My findings so far are, if i use the STM32CubeMX tool to generate a simple project with FreeRTOS enabled, the system works as expected using both ST-Link and JLink firmwares on the OB debugger.
But if i enable the tickless idle mode for FreeRTOS, the ST-Link firmware works as expected, while using JLink firmware starts giving me "Connecting to target...WARNING: Identified core does not match configuration. (Found: Cortex-M0, Configured: Cortex-M7)" after the first time i load my code on to the board. And i start getting unexpected interrupts.
I tested it with "empty" projects, that only do initialization and create two empty tasks.

What got me confused at the first place is, if i use AC6, than it would refuse to load the code after this error. But if i use TrueSTUDIO, it will give me the error but will still load the code, but then i start getting unexpected interrupts......

If i dont enable tickless idle feature, the JLink firmware for OB debugger works great! Including systemview and jscope.

Thanks,
Evgeny

This post has been edited 2 times, last edit by "evgeny_erlihman" (Nov 14th 2017, 3:49pm)


SEGGER - Nino

Super Moderator

Date of registration: Jan 2nd 2017

Posts: 437

9

Tuesday, November 14th 2017, 4:47pm

Hi Evgeny,

Thank you for the detailed analysis.

Quoted

But if i enable the tickless idle mode for FreeRTOS, the ST-Link firmware works as expected, while using JLink firmware starts giving me "Connecting to target...WARNING: Identified core does not match configuration.

The problem with most tickless mode implementations is that it enables low power modes on the target device.
This leads to disabling the debug interface. That is why J-Link throws an error as it is no longer guaranteed that the debug interface is still available and that the target device state is known.
ST-Link might work through pure luck or some special handling that ST has implemented. But usually a debug probe can't debug a target reliably anymore after a low power mode has been triggered.

Quoted

What got me confused at the first place is, if i use AC6, than it would refuse to load the code after this error. But if i use TrueSTUDIO, it will give me the error but will still load the code, but then i start getting unexpected interrupts......

This depends highly on how the J-Link has been implemented into the IDEs. It sounds linke TruStudio suppresses the actual target debug state from the J-Link so J-Link still tries to download the application even though it does not know the state the target device is in.

So to be able to debug your tickless mode application make sure all low power modes or other modes that alter the debug interface are not part of your application and add them later (if needed) when your application is functioning as expected.

Best regards,
Nino

Date of registration: Nov 1st 2017

Posts: 9

10

Tuesday, November 14th 2017, 4:55pm

Hi Nino,

The default tickless idle does not go into deep sleep states, so usually JLink is able to work with it just fine. From what i observe, once a tickless idle app is loaded on the target using OB with Jlink firmware, the target/OB gets into a state that even if i try to load an app without tickless idle i would still observe the same error. The only way to fix it, for me, was to revert back to ST-Link firmware, erase flash and upgrade to JLink firmware again.

Thanks,
Evgeny

SEGGER - Nino

Super Moderator

Date of registration: Jan 2nd 2017

Posts: 437

11

Wednesday, November 15th 2017, 3:52pm

Hi Evgeny,

Could you provide the example project so i can try to reproduce the issue?

Best regards,
Nino

Date of registration: Nov 1st 2017

Posts: 9

12

Wednesday, November 15th 2017, 7:50pm

Hi Nino,

Attached two projects, they are based of the same cube project with one difference - enabled/disabled tickless idle mode.
The only manual change in the code was to increase the delay time for both tasks for the MCU to actually go into tickless idle.
The projects are generated with STM32CubeMX 4.23.0 for SW4STM32 IDE.

The not working project will create the issue on the first time it runs. So you will observe the issue starting from the second load attempt.

Thanks,
Evgeny
evgeny_erlihman has attached the following files:

Date of registration: Nov 1st 2017

Posts: 9

13

Thursday, November 23rd 2017, 5:25pm

Hi Nino,

Not sure if it helps, but i tried the same thing with NUCLEO-L496ZG board, FreeRTOS and tickless idle. Havent observed any issues on it.

Thanks,
Evgeny

SEGGER - Nino

Super Moderator

Date of registration: Jan 2nd 2017

Posts: 437

14

Friday, November 24th 2017, 10:40am

Hello Evgeny,

Sorry for the delay in response.

Quoted

The default tickless idle does not go into deep sleep states

This statement is not true for the projects you provided.
The function prvIdleTask() calls portSUPPRESS_TICKS_AND_SLEEP which enables sleep mode when tickless mode is enabled.

Currently we do not do any special connect handling for the H7 like we do for other ST devices like the L4 series (that is why it works here).
We will see how and if it can be implemented for the H7 series as well.

Would you like to be added to the J-Link software update notification list,
so you get informed automatically when the new version becomes available?
Subscribe here: https://www.segger.com/notification/subs…php?prodid=7,94

Then you will be notified about the latest release notes and can directly see if the H7 tickless handler has been implemented.

Best regards,
Nino

Date of registration: Nov 1st 2017

Posts: 9

15

Friday, November 24th 2017, 3:39pm

Hi Nino,

Thank you for the information. Any estimate on when that might happen? Even a rough one?

Thanks,
Evgeny

SEGGER - Nino

Super Moderator

Date of registration: Jan 2nd 2017

Posts: 437

16

Friday, November 24th 2017, 4:31pm

Hi Evgeny,

We are currently pretty much packed with paid projects until the end of the year.
So a very rough estimate would be earliest end of Q1 2018.
Should that not be fast enough you have the option to implement the reset handler per J-Link Scriptfile yourself.
As basic debug support for the H7 is already given you only need to overwrite the default Reset behaviour for that device.
You can do that with the ResetTarget() function described in the J-Link User manual in the Scriptfile chapter.
More information about how to include the Scriptfile can be found here: https://wiki.segger.com/Adding_Support_for_New_Devices

Examples for other devices can be found in the J-Link installation folder under Devices/.

Best regards,
Nino