1

I'm using Rohitab's excellent API monitor tool to monitor the DLL calls that Keil uVision is making to Segger's JLinkARM.dll so that I can replicate them within an automated test environment.

As part of this I'm trying to understand the mechanism through which uVision communicates with the flash loader program to download the image being debugged.

I understand that uVision download's a flash loader program to the target device's RAM and that loader interacts with the onboard flash to erase it and download the new image, though I'm struggling to see the DLL calls which are made from uVision to actually stream the image down to the flash loader.

I would have expected to see a whole bunch of JLINKARM_WriteMem calls to stream the data down but I don't. I can see a bunch of JLINK_WriteReg and JLINK_ReadReg calls but not enough to comprise the image. My guess is they are for monitoring the flashing process. I know Jlink support a number of flash download related APIs but I don't see them used here. I don't see any paths being passed either. JLink's own log file is similarly unhelpful here. Is there some out of band mechanism I'm missing here?

Gregory Kuhn
  • 1,371
  • 1
  • 15
  • 26
  • 1
    Why would you not simply invoke Segger's own J-Flash tool in command line mode? Or even uVision itself in command line mode: https://www.keil.com/support/man/docs/uv4/uv4_commandline.htm. There seem few reasons you'd want to reverse engineer this, and any solution you devise will be specific to that one part, when both tools support hundreds of parts. – Clifford Jan 24 '21 at 21:35
  • Good point. I may go down that road. I've used a Python wrapper around the Jlink DLL in the past to great effect for creating an effective regression test bench. I asked this question as the mechanism wasn't clear to me. It's more a matter of curiosity rather that something that's going to actually stop me in my tracks. – Gregory Kuhn Jan 24 '21 at 22:00

1 Answers1

0

Sorry. I shouldn't be posting questions like this when I'm tired. JLINKARM_WriteMem is exactly the mechanism used. I don't know why I didn't see them the first time I tried it.

Gregory Kuhn
  • 1,371
  • 1
  • 15
  • 26