Author Topic: why my j-link V8 does not support STM32H750  (Read 1953 times)

0 Members and 1 Guest are viewing this topic.

Offline ali_asadzadeh

  • Super Contributor
  • ***
  • Posts: 1238
  • Country: ca
Re: why my j-link V8 does not support STM32H750
« Reply #25 on: July 23, 2020, 01:43:33 pm »
I have made another progress ^-^ I have Used DFU and flashed the part, my hardware is fine, the problem is the J-link-OB :palm: I can program and debug with the j-link OB another STM32 F0 part (STM32F030K6T6), so the j-link OB clone on easy padauk must be fine, has anybody got any success with j-link OB and STM32H750 or other H series parts?

If it fails I should go to DAP, and PORT the DAP to STM32F072 part :'( :'( :'( has anyone done it? and test it with STM32H?

I need debugging:-\
I'm a Digital Expert from 8-bits to 64-bits
 

Offline eliocor

  • Supporter
  • ****
  • Posts: 441
  • Country: it
    • rhodiatoce
 

Offline thm_w

  • Super Contributor
  • ***
  • Posts: 2296
  • Country: ca
Re: why my j-link V8 does not support STM32H750
« Reply #27 on: July 23, 2020, 11:58:16 pm »
AFAIK none of the clones >8 is really a proper clone like the V8 clones were (i.e. recognized by the Segger SW as legit). Lots of "V9" versions were just V8 with all the potential issues of blacklisted serial numbers or with some hacks like dual firmware to recover to an old version if bricked. V10 clones seem to need a hacked firmware. So you can't actually just use the newest firmware automatically etc.
I just don't get why anybody would invest more than 10€ or so in a clone that will be potentially bricked, blacklisted or get stuck with old firmware if you can buy a legit EDU for 50€ (even though the nag screen is not so easily disabled anymore with latest drivers from 2020, there's still an easy 99% solution).

I have a "v9.4" that updates firmware OK. Will check what chip is in there.

The one thing is instead of 22R series resistors inside they've used 220R. I'm not sure if this was a mistake or required due to some other function in the programmer.
I'm basing this value off of this V7 schematic, need to buy a proper Jlink and open it up to verify.

Whats the EDU solution?

edit: latest FW, micro is STM32F205
The V10 clones I see are using a LPC4337, I assume the genuine one is the same IC.
« Last Edit: July 24, 2020, 03:23:00 am by thm_w »
 

Offline abyrvalg

  • Frequent Contributor
  • **
  • Posts: 470
  • Country: ru
Re: why my j-link V8 does not support STM32H750
« Reply #28 on: July 24, 2020, 06:54:54 am »
Try disconnecting H750’s RST from J-Link (leaving just SWCLK and SWDIO) - any changes in the behavior?
 

Offline ali_asadzadeh

  • Super Contributor
  • ***
  • Posts: 1238
  • Country: ca
Re: why my j-link V8 does not support STM32H750
« Reply #29 on: July 25, 2020, 08:06:08 am »
Quote
Try disconnecting H750’s RST from J-Link (leaving just SWCLK and SWDIO) - any changes in the behavior?
I did not connected the RST from the j-link-OB to the STM32H, still same results, No luck. |O

Any one has the STM32H750 chip? please share your results
I'm a Digital Expert from 8-bits to 64-bits
 

Online ataradov

  • Super Contributor
  • ***
  • Posts: 6799
  • Country: us
    • Personal site
Re: why my j-link V8 does not support STM32H750
« Reply #30 on: July 25, 2020, 08:08:22 am »
There is no point. It (either debugger or the software) explicitly checks for the core type and refuses to work. It knows it is Cortex-M7, so the SWD connection is fine with reset or not.

You are out of luck. Think twice before going with Segger again.
Alex
 

Offline ali_asadzadeh

  • Super Contributor
  • ***
  • Posts: 1238
  • Country: ca
Re: why my j-link V8 does not support STM32H750
« Reply #31 on: July 25, 2020, 08:46:24 am »
Do we have V10 schematics?
I'm a Digital Expert from 8-bits to 64-bits
 

Offline robca

  • Regular Contributor
  • *
  • Posts: 131
Re: why my j-link V8 does not support STM32H750
« Reply #32 on: July 25, 2020, 03:55:31 pm »
There is no point. It (either debugger or the software) explicitly checks for the core type and refuses to work. It knows it is Cortex-M7, so the SWD connection is fine with reset or not.

You are out of luck. Think twice before going with Segger again.
I can't find exact release dates, but Jlink V8 is at least 10 years old. I don't think it's entirely unreasonable for a vendor to not update a 10 years old device

Also, the Segger documentation explains why they put "intelligence" in the Jlink instead of the PC debugger (https://www.segger.com/downloads/jlink/UM08001 section 1.5), and provide a way to add custom devices in the PC DLL (https://wiki.segger.com/Open_Flashloader#Create_a_Flash_Loader). It might be possible to support the M7 core that way (I doubt it will be "worth" doing it, but possible). So it's not an arbitrary decision to stop piracy, as much as the need to have new hardware to support the new core features in the probe itself for very good reasons

Having used a Jlink to debug nRF52 devices I came to appreciate how much value a Jlink adds compared to a normal SWD debugger (like ST Link). In the case of the nRF52, Nordic provides a sort of OS that takes care of pretty much all the Bluetooth and ANT communication stacks. The downside is that a standard breakpoint kills the communication stack, so you cannot single step into the code. Segger offers something called a Monitor Mode Debug (MMD) which keeps the processor running and uses a clever technique to still allow for single stepping thru code. It's truly life changing for a nRF52 developer (incidentally, Nordic provides an onboard Jlink in their development boards). The same with Segger RTT, much better than SWO in pretty much all scenarios

If the price to pay is that a user needs to buy a Segger Jlink every 15 years or so, it's not a bad tradeoff.

Lastly a real Segger Jlink EDU Mini that supports all the cores, costs <$20. So even hobbyist with no money can easily afford one. And, yes, you cannot do commercial work with the EDU license, but given that the majority of hobbyists sem to use unlicensed clones without a moral concern, I could argue that using a real EDU mini for semi-commercial work is at least morally equivalent to using a clone that comes with no license whatsoever
« Last Edit: July 25, 2020, 04:15:55 pm by robca »
 
The following users thanked this post: hans, enz, thm_w, soFPG

Offline abyrvalg

  • Frequent Contributor
  • **
  • Posts: 470
  • Country: ru
Re: why my j-link V8 does not support STM32H750
« Reply #33 on: July 25, 2020, 09:11:23 pm »
There is no point. It (either debugger or the software) explicitly checks for the core type and refuses to work. It knows it is Cortex-M7, so the SWD connection is fine with reset or not.
Surprising, OP's log from j-link OB shows no signs of refusal, it attempts to work with M7 core indeed (but fails on reset).  :-//
 

Online ataradov

  • Super Contributor
  • ***
  • Posts: 6799
  • Country: us
    • Personal site
Re: why my j-link V8 does not support STM32H750
« Reply #34 on: July 25, 2020, 09:16:02 pm »
If the probe actually includes core-specific logic, then it is understandable, but it is just a bad design.

The explanation about the inefficiencies of the protocol are also strange. Again, sounds like they just did nit do a good job designing their protocols. Probably on purpose.

With CMSIS-DAP you can do some very efficient transfers. Not many implementations do, since they are typically generic, but it is possible and not that hard.

There is still an argument for transferring some of the logic to the probe, of course, but it does not need to be core-specific.
Alex
 

Offline ali_asadzadeh

  • Super Contributor
  • ***
  • Posts: 1238
  • Country: ca
Re: why my j-link V8 does not support STM32H750
« Reply #35 on: July 29, 2020, 01:03:13 pm »
More Updates ;) >:D
Fuck Segger :box: :--, I have ported DAP to easy-pdk programmer for padauk , Now I can debug with it. So this programmer can work with padauk MCU and ARM Cortex parts, such a universal and cheap programmer. the problem with this DAP is the speed, because of STM32F072 and it's USB speed.
I'm a Digital Expert from 8-bits to 64-bits
 

Offline unitedatoms

  • Frequent Contributor
  • **
  • !
  • Posts: 324
  • Country: us
Re: why my j-link V8 does not support STM32H750
« Reply #36 on: August 01, 2020, 02:41:35 pm »
while manufacturer's ethics being discussed here, I may suspect the issue with M7 debugging could be caused by known bug in architecture.
https://www.eevblog.com/forum/microcontrollers/cortex-m7-debugging-bug/
Interested in all design related projects no matter how simple, or complicated, slow going or fast, failures or successes
 

Offline 0xdeadbeef

  • Super Contributor
  • ***
  • Posts: 1518
  • Country: de
Re: why my j-link V8 does not support STM32H750
« Reply #37 on: August 01, 2020, 06:26:01 pm »
while manufacturer's ethics being discussed here [...]
Felt more like discussing ethics of users. In hindsight I'm not even sure if the OP ever owned a legit J-Link.
Trying is the first step towards failure - Homer J. Simpson
 

Offline eliocor

  • Supporter
  • ****
  • Posts: 441
  • Country: it
    • rhodiatoce
Re: why my j-link V8 does not support STM32H750
« Reply #38 on: August 01, 2020, 07:21:48 pm »
To my knowledge the dismission by Segger of the V8 programmer was due ONLY for technical reasons: no more space available in the internal flash memory (64kB):
from ÷ to
0x0000 to 0x1FFF - bootloader (never updated by DLL)
0x2000 to ~0xF8FF - J-Link v8 programmer code (updated by DLL)
~0xFA00 to 0xFFFF - J-Link configuration (never modified by DLL)
 
If you extract from JLinkARM.dll the "latest" firmware for the v8 version (compiled on Nov 28 2014*) you'll find that Segger has used ALL of the available Flash resources.
This because there is NO MORE SPACE available!
This is the ONLY reason v8 units are no more supported, so it is USELESS to discuss about "ethics/greediness/..."!
     
     
 *) the May 27 2009 v8 firmware release had more than 0x4800 bytes free!
« Last Edit: August 01, 2020, 07:48:36 pm by eliocor »
 
The following users thanked this post: hans, thm_w

Offline abyrvalg

  • Frequent Contributor
  • **
  • Posts: 470
  • Country: ru
Re: why my j-link V8 does not support STM32H750
« Reply #39 on: August 01, 2020, 08:54:18 pm »
the problem with this DAP is the speed, because of STM32F072 and it's USB speed.
Porting it to Cypress FX2 for USB HS (and using one of those cheap AliExpress boards) could be interesting. HS has 8x higher frame rate, so the latency should be lower.
 

Online ataradov

  • Super Contributor
  • ***
  • Posts: 6799
  • Country: us
    • Personal site
Re: why my j-link V8 does not support STM32H750
« Reply #40 on: August 01, 2020, 08:56:58 pm »
FX 2 has very slow GPIO, so you would not get a very high speed on the SWD side.

You really need a real MCU with USB HS.
Alex
 

Offline abyrvalg

  • Frequent Contributor
  • **
  • Posts: 470
  • Country: ru
Re: why my j-link V8 does not support STM32H750
« Reply #41 on: August 02, 2020, 07:10:19 am »
Sure, a modern MCU with HS will be better, but I like the idea of widespread board reuse.
FX2’s GPIF FSM can be used under CPU control (wasting entire D0-7 bus to drive SWDIO, but who cares?) - serialize a data byte into GPIF buffer, fire the transfer (SWCLK can be generated by GPIF waveform on one of CTLx outputs), serialize next byte, check for completion, repeat. The CPU itself isn’t that fast, but GPIF parallelism can compensate something. I need to check the details.
« Last Edit: August 02, 2020, 07:12:27 am by abyrvalg »
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf