Marlin compile fail board/board.h: No such file or directory

Development Platforms
21

All right, after some time of trying and waiting for STlink I got it to compile and semi-run. BUT I screwed up to start with (as I do) I erased whole flash soo bye bye Malyan bootloader.
Well I got it all shifted to the correct vector and cleaned up some setting and it sort of runs now.

First problem I am not smart enough to get the ST-link cooperate with Platfomio at all so can not to any decent debugging.
And other problems I am encountering, I can not jog at all it clicks if I throw scope on step pin it pulses but enable pin pulses only for like one step pulse or so and that is it. When I run Gcode X and Y works fine. Z seems to be working ok.
Extruder stepper does not do anything at all no pulses on EN, Step or Dir in jog or Gcode.
USB connects to the pc but comes up with USB not recognised device malfunctioned.
And the final (so far) problem is that the Gcode only runs few lines and stops (running it from SD).
It seems to read temp’s ok and heating runs all right, pid need definitely tuning.
Extruder FAN works ok PWMing ok.
Screen reboots (maybe with main board) randomly.

so yeah I would love some help I am not smart enough to get all these issues sorted.
Any help would be appreciated.
I actually hit the wall and have no idea where to start troubleshooting this.

22

With just debug_tool = stlink in the platformio.ini you should get a working debug experience within Visual Studio Code. What’s the exact error message?

23

I will give it a go on monday unless we all get corona quarantined here. I have set the debug_tool but it keeps throwing an error I will post him on monday.
I just had a thought is marlin actually able to run proper on f070? f103 have some additional peripherals not sure if they are needed or not or at least make it easier.
I have f103cb on hand I could throw in, in the worst case.

24

Right I have managed to try the debug and the result is

arm-none-eabi/bin/ld.exe: address 0x8020080 of .pio\build\malyanm200v2\firmware.elf section .rodata' is not within region FLASH’
arm-none-eabi/bin/ld.exe: .pio\build\malyanm200v2\firmware.elf section .init_array' will not fit in region FLASH’
arm-none-eabi/bin/ld.exe: address 0x8020080 of .pio\build\malyanm200v2\firmware.elf section .rodata' is not within region FLASH’
arm-none-eabi/bin/ld.exe: region `FLASH’ overflowed by 1172 bytes

25

When debugging, PlatformIO will recompile everything without optimization (-O0 instead of -Os) which does enable proper debugging but enlarges the file size.

According to Redirecting... you might try adding to your platformio.ini

debug_build_flags = -O1 -ggdb3 -g3

This should try compilation with -O1 aka some optimization but still kinda debuggable.

26

Right, I think I have solved few issues:
If the following are set to true it only tickles stepper enable but does not move at all (kind of stupid option I guess (unless I dont get the deeper meaning). I think it should stay enabled until step train stops at least see screen captures.

// Disables axis stepper immediately when it’s not being used.
// WARNING: When motors turn off there is a chance of losing position accuracy!
#define DISABLE_X false
#define DISABLE_Y false
#define DISABLE_Z false

20131026115219
20131026115219800×600 38.9 KB
20131026120228
20131026120228800×600 39.3 KB

to compile in debug I need to set

debug_build_flags = -Os

but I am getting this error

PlatformIO Unified Debugger → Redirecting...
PlatformIO: debug_tool = stlink
PlatformIO: Initializing remote target…
xPack OpenOCD, 32-bit Open On-Chip Debugger 0.10.0+dev (2019-07-17-07:34)
Licensed under GNU GPL v2
For bug reports, read
OpenOCD: Bug Reporting
Info : The selected transport took over low-level target control. The results might differ compared to plain JTAG/SWD
srst_only separate srst_nogate srst_open_drain connect_deassert_srst
Info : tcl server disabled
Info : telnet server disabled
Info : clock speed 1000 kHz
Info : STLINK V2J36S7 (API v2) VID:PID 0483:3748
Info : Target voltage: 3.146323
Error: init mode failed (unable to connect to the target)
.pioinit:13: Error in sourced command file:
Remote communication error. Target disconnected.: Success.

Still two important issues are remaining. When I run Gcode from sd card it stops after few lines.
And Usb is not working

27

Okay it detected the STLink but couldn’t connect to the target MCU. How have you wired the STLink and the STM32 chip? Needs GND, 3V3, SWCLK, SWDIO and maybe NRST.

28

It works fine through ST-LINK Utility, I have tried connecting NRST to rst pin on the ST-LINK or grounding manually and release when the debug tries to connect. nothing works.
The only thing I could think of is that the SWCLK and SWDIO pins are set wrong by marlin but I can not figure out how to set it right in marlin.

29

I’m making progress with the uploading of firmwares. Currently I’m experiencing the following issues:

  • After compiling Marling and configuring all the right ports, I connect the board through USB and a get a device called “STMicroelectronics Virtual COM Port”, which on Windows gives me a error code 10 and can’t manage to connect. Suspect the cause could be some port misconfiguration on Marlin, but I think I got it right. @maxgerhardt do you know if maybe some build variable could be missing?
  • I need to build the debug binaries with debug_build_flags = -Os… but because of that I don’t get any debug symbols (I think). What would be the right balance so the binary fits in 128KB but lets me debug? -O1 -ggdb3 -g3 doesn’t seem to reduce the output size enough
  • The upload process (using OCD + STLink) in Windows seems unreliable… lots of the time I have to unplug both connections to the board and start again because it can’t connect (seems to be “stuck” in some state). I don’t understand why, guess I’ll try with Linux to see if it behaves better.

Two things I had to do/happened while getting here:

  • I had to solder a cable to the NRST pin on the STM32F070CB, otherwise STLink couldn’t reset and thus connect.
  • @myval, I also botched the bootloader while removing the protection lock (setting the level to 0). Maybe if I used OpenOCD from the start I could have avoided it… but for me at least the erase killed the bootloader. Managed to get it running following this: Recovering a bricked MP Mini Delta 3D Printer | Arko's Blog The STM32F0 is the same, so maybe you can reuse some of that.

If somebody has any answers or suggestions about how to advance, please let me know!

Good luck

30

Have you installed STSW-LINK009 - ST-LINK, ST-LINK/V2, ST-LINK/V2-1, STLINK-V3 USB driver signed for Windows7, Windows8, Windows10 - STMicroelectronics? Maybe you’re missing the driver / right driver.

Well after O1 there’s only O2 and Os :confused: Debug symbols are still compiled in via -ggdb3 but the compiled code will be more optimized so it can jump between lines and skip explicitly displaying some variables. You still trace the control flow and if there’s a variable you need to print you can maybe print over the USB serial.

Is the power supply for the board stable?

This may also be resolvable by doing a software SWD reset instead of relying on the hardware reset. When you du a verbose upload (pio run -t upload -v) you should see the openOCD command that’s invoked with some cfg scirpt for the STM32 controller. In that file you can modify the reset_config to values like reset_config none separate or reset_config srst_only srst_nogate .

31

We are in lockdown so I can not go to my workshop at the moment to check anything I have my board connected to ST-Link here with me and a scope that is about all I can do. I have done some changes to the config I want to try and see. But I still can not crack the debugging it just will not connect to the board.

The botched bootloader I have fixed simply by changing to start from 0x08000000 I don’t need a bootloader at all and it saves bit of space for marlin.

I don’t have any issue uploading with ST-Link util or STM32Cube Programmer but I can not connect to the board through Platformio at all.

I will try to install driver from ST like @maxgerhardt said and give the USB another go.
and will try the SWD reset trick.

Just wondering if anyone had any luck running marlin on F070CB at all ever?

32

Thanks for your reply @maxgerhardt ! Lots of useful tips and info :smile:

Regarding the different topics:

  • Virtual COM driver: Haven’t tried yet as I want to get debugging running first, but will try it. Thought that maybe I was also missing some build param (such as PIO_FRAMEWORK_ARDUINO_ENABLE_CDC or something like that)
  • Optimization: I was missing -ggdb3 but I’ve realizaed that my issue was not even the lack of debug symbols but that I never actually run the main function…
  • Power supply: Is stable, yes… but maybe my wiring/soldering is a bit wonky. Revisited it and stability seems to have improved.
  • NRST pin: Still connecting from chip to STLink, but set reset_config to reset_config srst_only srst_nogate on the file (for this board, st_nucleo_f0.cfg). That seems to also have improved stability and now uploads seem to work. Aditionally, I’ve replaced source [find interface/stlink.cfg] with source [find interface/stlink-v2.cfg]

My current issue is that firmware doesn’t run, as in… the default breakpoint on main is never reached (nor any other breakpoint I add). Using the debugger commands, I’m trying to find out what’s happening so I manually restart the board

> interrupt
> monitor reset halt

xPSR: 0xc1000000 pc: 0x00010100 msp: 0x464c457c
target halted due to debug-request, current mode: Thread 
xPSR: 0xc1000000 pc: 0x00010100 msp: 0x464c457c
{"token":58,"outOfBandRecord":[],"resultRecords":{"resultClass":"done","results":[]}}

and then step, showing me that I end up in some “dead end” before even reaching the main function.

> nexti
halted: PC: 0x00010102
> nexti
halted: PC: 0x00010104
> nexti
halted: PC: 0x0000d1b4
> nexti
halted: PC: 0x00000000
> nexti 
halted: PC: 0xfffffffe

It’s like I’m hitting an exception or starting from the wrong PC. Any hints about what I could be doing wrong?

EDIT ok, think I was writing Marlin to 0x80000000 and destroying the booloader’s vector table and such. I’ve set the buildsection of buildroot/share/PlatformIO/boards/malyanM200v2.json inside Marlin’s directory with content from ~/.platformio/platforms/ststm32/boards/malyanm200_f070b.json

"build": {
    "cpu": "cortex-m0",
    "extra_flags": "-DSTM32F070xB",
    "framework_extra_flags": {
      "arduino": "-DVECT_TAB_OFFSET=0x2000 -DCUSTOM_STARTUP_FILE"
    },
    "f_cpu": "48000000L",
    "mcu": "stm32f070rbt6",
    "genericvariant" : "MALYANM200_F070CB",
	  "variant": "MALYANM200_F070CB",
    "vec_tab_addr": "0x8002000"
  },

Now after reseting I get to

xPSR: 0xc1000000 pc: 0x08000198 msp: 0x20004000

That seems a more reasonable PC. Still, I never reach main. If I step instruction by instruction, there seems to be a loop (probably a normal one) on the bootloader. If I let it continue and then interrupt, I still end up at 0xfffffffe

After this, I’m kind of lost again :scream:

34

I have changed this in
ldscript.ld
FLASH (rx) : ORIGIN = 0x08000000, LENGTH = 128K

variant.cpp
#define FW_START_ADDR 0x08000000

malyanM200v2.json
{
“build”: {
“cpu”: “cortex-m0”,
“extra_flags”: “-DSTM32F070xB”,
“f_cpu”: “48000000L”,
“mcu”: “stm32f070cbt6”,
“genericvariant” : “MALYANM200_F070CB”,
“variant”: “MALYANM200_F070CB”,
“vec_tab_addr”: “0x8000000”
},
“debug”: {
“jlink_device”: “STM32F070CB”,
“default_tools”: [
“stlink”
],
“onboard_tools”: [
“stlink”
],
“openocd_board”: “st_nucleo_f0”,
“openocd_target”: “stm32f0x”
},
“platform”: “ststm32”,
“frameworks”: [
“mbed”,
“stm32cube”,
“arduino”
],
“name”: “Malyan M200 V2/Delta”,
“upload”: {
“maximum_ram_size”: 16384,
“maximum_size”: 131072,
“protocol”: “stlink”,
“protocols”: [
“jlink”,
“stlink”,
“blackmagic”,
“mbed”
]
},
“url”: “NUCLEO-F070RB | Mbed”,
“vendor”: “Malyan”
}

35

Is it possible to just do that though? I think the data at 0x08000000 needs some structure,

Following the post at Recovering a bricked MP Mini Delta 3D Printer | Arko's Blog, seems like a pointer to the reset routine is stored at 0x08000004, which is the first thing ran by the processor. That post says that on the firmware.bin being discussed, then it jumps to 0x080171F4 (even though the address stored is 0x080171F5, because of thumb2 reasons).

reset_vector_map
reset_vector_map923×1007 29.7 KB

If that’s the case, writing the firmware.bin directly to 0x08000000 doesn’t seem the way to go. You need to set the pointer and then write the firmware to the address you point to (I guess)

36

well that all should be taken care off by marlin/ platformio/ gcc. I stopped digging too deep into it since I am not a programming expert (just wanted to get my malyan to run marlin :slight_smile: )
The only two things I am having problems with are USB and the Gcode runs few lines from sd card only. everything else seems to be ok.
Of Course I don’t have any bootloader soo can not do sd card updates (not a big deal for me)

I have tried the fix from the link you sent for the delta and it works sort off it boots runs but the SD update does not work. This is the way I am going to run it now to get few jobs done and figure out the marlin later.

37

@myval apologies if I was rude. I’m also kind of lost here and making my way through, not an expert either by any means. I’m glad the “hacked bootloader” worked on your board too. With it, SD update didn’t work either for me… then I found out the Marlin4MPMD includes a copy of the stock bootloader, which restores the SD Update functionality! If the “hacked” one worked for you, I guess this one will too: Marlin4MPMD/bootloader binary at master · mcheah/Marlin4MPMD · GitHub

The readme file mentions that the bootloader is “optional if debugging directly on target hardware” so I guess your approach is right and should work, even though I couldn’t make it work. I’m also trying to make it work with Marlin starting at 0x08002000 so then I can update via SD.

Also ended up in you situation a couple of times:

.pioinit:13: Error in sourced command file:
Remote communication error. Target disconnected.: Success.

Would like to better understand why this happens in the first place, but at least (I think) I found a way out when OpenOCD doesn’t wan’t to connect (but the STLink Utility does):

  • Connect via STLink Utility
  • Erase chip

After that, uploads work again (util I happen to break anything at some point and then have to repeat) :man_shrugging:

I think now I’m a flow where I can upload reliably and restore booloaders or whatever I need, check what’s in memory, even potentially following up the disassembly with Binary Ninja… but still can’t reach the actual code.

@maxgerhardt Is it necessary to rename ~/.platformio\packages\framework-arduinoststm32\variants\MALYANM200_F070CB\startup_M200_f070xb.S? Think that when I do I end up with a very small binary, but if I make it availble by renaming it again and use the debugger, I end up with this weird pc. Checking the memory of the STLink I see there’s a ELF header at 0x08000000, with part of it at 0x08000004 setting the wrong PC for the RESET_VECTOR.

What I would like to do is compile something with Platformio (Marlin in this case) so the actual code (no ELF headers or anything) ends up at 0x08002000. This way, I can keep my bootloader, which after running will leave me there and start debugging from that point. I’m a bit lost with which files/settings (json files, variant, .S and the likes) would be neccesary to configure or combine so I can get there (leave the bootloader and load the debug firmware at 0x08002000).

Thanks again!

38

Rude? no way you all right. On the same boat here. I am not good at writing long stories so kind of short to the point if I can.

unfortunately I can not do much now thanks to that chinese mickey the microbe.

39

@drewler If I could figure out how to upload it to git I would share my changes with you. I don’t understand why it is so complicated.

40

If it’s just a single file that’s been changed, you can use a pastebin site like https://hastebin.com/ :wink: Otherwise, Github Gists are also a handy and quick option.

41

I look forward to seeing how this is resolved. Over in Marlin-land we’re still referring users to Arduino IDE for Malyan M200 build, but PIO is the future….