How do I build an example program using VSCode?

I am trying to set up VS Code to build the “blinky” example for the MAX32620FTHR connected to the MAX32625PICO. All of that was fairly simple to get running using the MBed Studio – I just built the example with the PICO cabled up to my MacBook, and the generated executable auto-magically got installed and started running on the FTHR.

I’m now trying to get the same kind of build with VS Code. I was directed to the VS Code setup at Project Setup: VS Code · mbed-ce/mbed-os Wiki · GitHub which got me partway through, but I’m had some difficulty understanding the UPLOAD_METHOD entry in the cmake-variants.yaml file. I copied the yaml file I found at the project setup link, and just changed the target and upload stuff, as follows:

  default: Debug
      short: Debug
      long: Emit debug information and don't optimize
      buildType: Debug
      short: Develop
      long: Emit debug information but also optimize
      buildType: Develop
      short: Release
      long: Optimize generated code
      buildType: Release
  default: MAX32620FTHR
      short: MAX32620FTHR

The UPLOAD_METHOD was just a guess. The choices were MBED and PYOCD, and PYOCD seemed to be supported by the MAX32620FTHR, although I’m not sure about that.

When I selected a configuration, I got cmake configuration errors:

[cmake] CMake Error at mbed-os/tools/cmake/UploadMethodManager.cmake:24 (message):
[cmake] The upload method PYOCD is not enabled in the config code for this target
[cmake] -- set PYOCD_UPLOAD_ENABLED to TRUE to enable it.
[cmake] Call Stack (most recent call first):
[cmake] mbed-os/CMakeLists.txt:219 (include)
[cmake] -- Configuring incomplete, errors occurred!
[cmake] See also "/Users/howardharkness/arm-workspace/build/CMakeFiles/CMakeOutput.log".
[cmake] See also "/Users/howardharkness/arm-workspace/build/CMakeFiles/CMakeError.log".
[proc] The command: /opt/homebrew/bin/cmake --no-warn-unused-cli -DMBED_TARGET:STRING=MAX32620FTHR -DCMAKE_EXPORT_COMPILE_COMMANDS:BOOL=TRUE -DCMAKE_BUILD_TYPE:STRING=Debug -DCMAKE_C_COMPILER:FILEPATH=/opt/homebrew/bin/arm-none-eabi-gcc -DCMAKE_CXX_COMPILER:FILEPATH=/opt/homebrew/bin/arm-none-eabi-g++ -S/Users/howardharkness/arm-workspace -B/Users/howardharkness/arm-workspace/build -G Ninja exited with code: 1 and signal: null

At this point, I was scratching my head wondering if I even need the UPLOAD_METHOD, and I can’t find anything like that in the MBed Studio directory. However, I tried leaving that out of the yaml file, and got the same errors.

I concluded that I need to have a set(PYOCD_UPLOAD_ENABLED TRUE) in one of my CMakeLists.txt files (assume the topmost). That appeared to work — the make configuration completed, and the build finished, but I was unable to copy the resulting Example.bin file to the FTHR board. There was an error dialog that said “The operation can’t be completed because an unexpected error occurred (error code -1407)” I googled that error message, but didn’t get any hits that made sense to me.

In addition to the Example.bin, I saw that VSCode built Example.elf and Example.hex, neither of which I recognize, and neither of which appears to be an executable. The hex file resembles stuff I worked with 35 years ago — is that something I can download to the FTHR with some translation tool?

So, how do I get past this? I just want to build a “Blinky” example using VSCode, and run it on the FTHR.

Ah right. The MBED upload method duplicates Mbed Studio’s method of copying the bin file onto the device. If you set


it should work.

Alternately, there’s a good chance that pyocd is failing because it does not have the correct CPU set. You need to have

set(PYOCD_TARGET_NAME max32620)

to configure that. Using PYOCD instead of MBED as your upload method has the benefit of enabling debugging, which the file-copy method does not support.

Thank you! That allowed me to build, download, and run an example program. Still have some things to figure out, though.

For instance, I’m still getting a popup dialog indicating that an operation can’t be completed because one or more required items can’t be found. That’s a bit puzzling, because I was able to see the “blinky” (with some mods to make sure I could tell it was the right version) application running properly on the MAX32620FTHR. (Edit: I made another minor change, re-built, and downloaded again, and did not see the error pop-up. Strange. Must’ve been a temporary glitch)

For now, the main thing I noticed was that the .bin file took a long time to download. When I checked the size, it was 291K – the same program build with MBed Studio was only 14K. I’m guessing I have some configuration that is not set correctly, probably the “bare metal” setting in MBed Studio (for this first application, I don’t need preemptive multitasking or much of anything fancy). Once I figure that one out, I will attempt to use the debugger. Another minor problem is that I can’t find the printf output – probably yet another setting I missed.

I appreciate the help. It got me off of the critical path for this project! Any other hints/suggestions are warmly welcome.

Interesting. I tried compiling one of the basic tests for MAX32620FTHR (I don’t have one of these boards to test with so I haven’t used it before). The sizes in the build report look good:

| Module                   |         .text |       .data |        .bss |
| CMakeFiles\mbed-os.dir   | 14912(+14912) |   692(+692) | 6740(+6740) |
| [fill]                   |       74(+74) |       7(+7) |   482(+482) |
| [lib]\c.a                |   5836(+5836) | 2108(+2108) |     89(+89) |
| [lib]\client_userio.a    |   1480(+1480) |     56(+56) |       8(+8) |
| [lib]\gcc.a              |     760(+760) |       0(+0) |       0(+0) |
| [lib]\mbed-greentea-io.a |       72(+72) |       0(+0) |       0(+0) |
| [lib]\mbed-unity.a       |     834(+834) |       0(+0) |   160(+160) |
| [lib]\mbed-utest.a       |   3360(+3360) |     13(+13) |   201(+201) |
| [lib]\misc               |     180(+180) |       4(+4) |     28(+28) |
| hal\tests                |     236(+236) |       0(+0) | 2148(+2148) |
| Subtotals                | 27744(+27744) | 2880(+2880) | 9856(+9856) |
Total Static RAM memory (data + bss): 12736(+12736) bytes
Total Flash memory (text + data): 30624(+30624) bytes

But I see the same thing, that the bin file is much larger than you would expect.

It’s really odd. If you look at the .bin file, you can see it’s about the same size as the device RAM, and entirely zeroes. By doing a readelf on the elf file, I can see that it contains this load command:

Type           Offset   VirtAddr   PhysAddr   FileSiz MemSiz  Flg Align
LOAD           0x008c00 0x20000c00 0x00008c00 0x00000 0x3f000 RW  0x200

This means that it’s trying to zero nearly the entire RAM space (0x20000c00 to 0x2003FC00) by appending zero bytes to the output file and then copying them to RAM. This is not normal linker behavior, normally the remainder of the RAM is supposed to be uninitialized and then the startup code zeros bss and sets up other sections. I can only assume there’s some sort of bug in the MAX32620’s GCC linker script.

For now, things should work OK, just with some wasted memory. I’ll keep looking into this.

Ah, I think it’s because some symbols are ending up in the .stack_dummy section which is placed at the end of RAM. Just need to figure out why that is.

That is really strange. My .bin file for Nucleo-F767ZI has only 50kB, but when I tried compile same code for max32620 (I don’t have this board) then the size is really huge 200kB+
BR, Jan

Strange, but since this appears to only affect the load time for the image, it is not a critical concern to me on my current project. Instead of being only a second or so, it’s on the order of 20-30 seconds; a minor annoyance, not a biggie. For now, I’m going to put this problem on the back burner, and just monitor the group in case somebody can point out something I’m doing wrong (or sub-optimally).

I suspect that there is a flag setting somewhere that I’m missing. There are a lot more “moving parts” to embedded systems development than I remember from 10 years ago :slight_smile:

I’m 95% sure this is a linker script bug on the Mbed side, not related to anything you did. It’s showing up now because Mbed CE uses the GNU Arm toolchain while Mbed Studio uses Arm Compiler 6, and the two toolchains use different linker scripts.

Standby for updates, I’ll work on a fix.

I tried regular MbedOS under MbedStudio with GCC for this target and the size of .bin file is also huge (280kB). So you are right from my point of view.

BrR, Jan

I definitely appreciate your effort!

I’m having some other problems that appear to be specific to VSCode. Is there a better place to ask about that?

Ah, I think I worked out what’s going on. The issue seems to be that the startup ASM code for MAX32620FTHR is putting symbols into the .stack section, which goes at the end of RAM and is supposed to be empty. This is causing the linker to fill nearly the entire ram space with zeros, making the bin file much bigger than it needs to be (and eating up 256k of flash space).

I’ve confirmed that going into targets/TARGET_Maxim/TARGET_MAX32620C/device/TOOLCHAIN_GCC_ARM/startup_max32620.S and deleting the following block (which seems to do nothing that the linker script doesn’t already do) fixes the size issue:

    .section .stack
    .align 3
#ifdef __STACK_SIZE
    .equ    Stack_Size, __STACK_SIZE
    .equ    Stack_Size, 0x00001000
    .globl    __StackTop
    .globl    __StackLimit
    .space    Stack_Size
    .size   __StackLimit, . - __StackLimit
    .size   __StackTop, . - __StackTop

    .section .heap
    .align 3
#ifdef __HEAP_SIZE
    .equ    Heap_Size, __HEAP_SIZE
    .equ    Heap_Size, 0x00004000
    .globl  __HeapBase
    .globl  __HeapLimit
    .space  Heap_Size
    .size   __HeapBase, . - __HeapBase
    .size __HeapLimit, . - __HeapLimit

@howard.harkness Can you try this and make sure that the code still runs OK?

Maybe make a new thread? I’ll check it out and see if I can help.

I’ve been using the MAX32620FTHR board recently, and I added further information to the target.json file for the board obtained from the MAX32620 Rev C user guide:

        "mbed_rom_start": "0x00000000",
        "mbed_rom_size": "0x00200000",
        "mbed_ram_start": "0x20000000",
        "mbed_ram_size": "0x00040000",

So, when I compiled I get 19.1kB for the mbed-os-example-blinky.bin file and here is the breakdown following the compile:

| Module               |     .text |   .data |     .bss |
| [lib]/c_w.l          |  4126(+0) |  16(+0) |  348(+0) |
| [lib]/fz_wm.l        |    26(+0) |   0(+0) |    0(+0) |
| anon$$obj.o          |    32(+0) |   0(+0) | 1024(+0) |
| main.o               |    60(+0) |   0(+0) |    0(+0) |
| mbed-os/cmsis        |  7312(+0) | 168(+0) | 6610(+0) |
| mbed-os/connectivity |    62(+0) |   0(+0) |    0(+0) |
| mbed-os/drivers      |    64(+0) |   0(+0) |    0(+0) |
| mbed-os/hal          |   262(+0) |   0(+0) |    2(+0) |
| mbed-os/platform     |  4487(+0) |  64(+0) |  340(+0) |
| mbed-os/rtos         |   194(+0) |   0(+0) |    0(+0) |
| mbed-os/targets      |  2366(+0) | 260(+0) |  377(+0) |
| Subtotals            | 18991(+0) | 508(+0) | 8701(+0) |
Total Static RAM memory (data + bss): 9209(+0) bytes
Total Flash memory (text + data): 19499(+0) bytes

Did you apply my ASM fix? Also, are you using GNU Arm? The issue only shows up with that toolchain.

I did not apply ASM fix. I was using the default Arm Compiler 6. If I try to use GCC_ARM compiler it fails to compile.

I tried the ASM fix. It reduced the bin file size to 26K, and it runs properly. Haven’t completely understood it yet, but it does do the trick.

I’m also still attempting to understand the target.json fix suggested by @gerriko

I have not found a file called “target.json”. Is that something I need to add, and if so, where?

BTW, the toolchain I’m using is GCC 10.3.1 arm-none-eabi

1 Like

PR created to fix this: MAX32620C: Fix ASM that interfered with the GCC linker script and made the linker try to zero the entire RAM space by multiplemonomials · Pull Request #75 · mbed-ce/mbed-os · GitHub

Gerriko’s solution is not solution in this case, from my point of view. He used MbedStudio with AC6, but we are talking about GCC. The default Compiler in Mbed Studio is AC6 (Arm Compiler 6). Because Mbed-CE can not use AC6 (because of Licence) then is necessary to use GCC.
Above I tried change settings of Mbed Studio to GCC to compare with Mbed-CE result. This probably led to a misunderstanding.

The targets.json file is in the targets folder of Mbed-Os. This file contains default settings for your target Max32620FTHR. There just missing settings for Bootloader and the MbedStudio report a Configuration error.

Configuration error: Bootloader not supported on this target. ROM start not found in targets.json.
Configuration error: Bootloader not supported on this target. RAM start not found in targets.json.

The folder for Max32620 contains predefined toolchain specific settings for this target and there is the place where Jamie did the fix for GCC.

BR, Jan

1 Like