PacktPublishing/Hands-On-RTOS-with-Microcontrollers

Bugs in the *.jdebug files, e.g., Chapters5_6.jdebug

Closed this issue · 2 comments

jimyuill commented

Brian,
There appear to be several bugs in the Ozone project-file Chapters5_6.jdebug.
The bugs prevent Ozone from loading the project properly, and also from downloading the program to the board.
Three lines in the file are incorrect and there's a missing line. Details are below, with fixes.
Also, the attached file has fixes.
These bugs seem to be in all of the chapters' *.jdebug files, e.g., Chapters 6 to 8.

FYI, I've run into other bugs in the code, book, and systems (Ozone and SystemView).
I've been making a note of them, and fixes.
I can provide more info, if of interest: jimyuill -AT- gmail -DOT- com .

Sincerely, your book is really good! I'm half-way through it, and learning a lot.

  1. #################
  • Apparent Bug: Specifying "JTAG" produces errors in Ozone.
  • Incorrect line: Project.SetTargetIF ("JTAG");
  • Fixed line: Project.SetTargetIF ("SWD");
  • Description:

With "JTAG", Ozone gives the following error messages, when running "Download & Reset Program"

Debugger tries to select target interface JTAG.
This interface is not supported by the connected emulator.
Selection will be ignored by the DLL.
...
Failed to activate SWO data capture: target interface not set to SWD

A similar problem in using JTAG was reported on this web-page, and a SEGGER tech said to use SWD instead.
https://forum.segger.com/index.php/Thread/4990-SOLVED-Problems-connecting-to-CC3220SF-via-J-Link/

Using "SWD" fixed the problem for me.

  1. #################
  • Apparent Bug: incorrect svd file specified
  • Incorrect line: Project.AddSvdFile ("C:\Program Files (x86)\Atollic\TrueSTUDIO for STM32 9.3.0\ide\plugins\com.atollic.truestudio.tsp.stm32_1.0.0.20190212-0734\tsp\sfr\STM32F7x7.svd");
  • Fixed line: Project.AddSvdFile ("C:\ST\STM32CubeIDE_1.5.1\STM32CubeIDE\plugins\com.st.stm32cube.ide.mcu.productdb.debug_1.5.0.202011051456\resources\cmsis\STMicroelectronics_CMSIS_SVD\STM32F767.svd");
  • Description:

The book's instructions do not include installing TrueStudio.
So, the specified file is not found.
The instructions require installing STM32CubeIDE, which has that svd file.

  1. #################
  • Apparent Bug: needed svd file is not specified
  • Added line: Project.AddSvdFile ("C:/Program Files/SEGGER/Ozone/Config/CPU/Cortex-M7.svd");
  • Description:

When opening the project in Ozone, it gives a warning message:

No CPU register set description file specified, loading default: C:/Program Files/SEGGER/Ozone/Config/CPU/Cortex-M7F.svd.
Project.AddSvdFile ("C:/Program Files/SEGGER/Ozone/Config/CPU/Cortex-M7F.svd");

However, that default file is incorrect: Cortex-M7F.svd
Cortex-M7F has an FPU.
The dev-board processor is just a Cortex-M7, without an FPU.
So, Cortex-M7.svd should be specified.

  1. #################
  • Apparent Bug: elf file specified is incorrect
  • Incorrect line: File.Open ("C:/projects/packtBookRTOS/freeRTOS_Nucleo767/Debug/freeRTOS_Nucleo767.elf");
  • Fixed line: File.Open ("C:\projects\packtBookRTOS\Chapters5_6\Debug\Chapter5_main.elf");
  • Description:

Specifying the FreeRTOS elf here is confusing

Chapters5_6.zip

.

brian-amos-embedded commented

Hi jimyuill,

Thanks for taking the time to outline the problems you encountered. In general, the *.jdebug files are really more of a starting point, since Ozone uses absolute path names when it writes them. It is expected that you'll need to point them to your exact location for *.elf files, at a minimum.

  1. Correct, SWD is used on the Nucleo board. As soon as you attempt to connect to a processor, Ozone should have resolved this for you (without resorting to modifying the file by hand).
  2. Thanks for pointing this out, the original IDE used was actually TrueStudio (then things were ported to STMCubeIDE later). This is another left-over from the TrueStudio installation I was originally using - it should be updated. Unfortunately, I suspect the STMCubeIDE path will be pretty fragile, and will be specific to windows installations.
  3. The dev board used has an FPU on the processor (see https://www.st.com/en/microcontrollers-microprocessors/stm32f767zi.html ). Rather than letting Ozone specify a "generic" M7-based svd file, simply remove the line and use the svd you identified in step 2 above, since it is specific to the MCU being used. By default, Segger uses a generic M7* svd file - you won't have access to all of the peripheral registers. STM32F767.svd is specific to the processor on the dev board being used, so it has all of the peripheral registers fully defined and will give you more insight as to what's going on.
  4. As mentioned on page 140, if your absolute paths are different from the ones I used during development, you'll need to point Ozone at the exact elf file you'd like to debug. Since I wasn't going to create an individual *.jdebug file for every example, this step needs to be performed when debugging different examples anyway.

I've lent out my dev board at the moment, but after I get it back I'll take a look improving the *.jdebug files so they present fewer problems the first time they're used.

I'm glad you've found the book useful so far! If you run into other problems, feel free to raise an issue here, I'm interested in improving the experience.

jimyuill commented

Brian,
Thanks for your reply.

FYI, I got the impression from the book that the *.jdebug files provided would work as-is.
When I used the *.jdebug file for Chapters 5&6, there were several errors reported on the console, as I described.
On the console, error messages are in red text, and there was no differentiation between warnings and show-stoppers.
So, I went about trying to fix all of them, assuming they were show-stoppers.

As a suggestion, it would be helpful to provide more info on how to get the *.jdebug files set-up.

Again, overall, the book is really good, e.g., good selection of topics, explained well, and well-written.

Thanks,
Jim