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

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”
}

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).

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)

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.

@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!

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.

@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.

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.

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….

The thread is so long, sorry. Could someone prepare a project that does not work with PlatformIO and works with Arduino? We would be glad to fix this ASAP. Thanks!

Right Boys I got it running! Well sort off anyway. Compiles in Platformio like a charm, Everything but two things work as far as I can see.
Controlling it over WIFI does not work apart from I thing cancel the print.
USB connection does not work at all and in windows device manager I get:
This device cannot start. (Code 10)
{Operation Failed}
The requested operation was unsuccessful.

I would like to do PID autotune but not sure how to attack it without USB or WIFI.
I am about to try print from SD card will see how that goes.

I am one big ear for additional pointers to get the WIFI and USB running propper.

If anyone is interested I got Gcode going over WIFI or IP to be more accurate.
maybe you @maxgerhardt might be interested to shove it in to your repo.
Some C expert should check the C grammar (I am no software dude by any means I just got it going mainly by accident haha :slight_smile: )
@ivankravets I prefer to stay with Platformio I think it is better environment (at least for my brain power)

BTW yess it is bloody messy I know I just needed to get it going.

// Parse LCD commands mixed with G-Code

void parse_lcd_byte(byte b) {

  static bool parsing_lcd_cmd = false;

  static bool parsing_lcd_gcode = false;

  static char inbound_buffer[MAX_CURLY_COMMAND];

  static char a = '\0';

  char c;

  c = b & 0x7F;

  if (!parsing_lcd_cmd && !parsing_lcd_gcode) {

    if ( c == '{' ) {                       // A line-ending or opening brace

      parsing_lcd_cmd = true;               // Brace opens an LCD command

    }

    else if (c == '\r') {

      a=c;

    }

    else if (c == '\n' && a == '\r'){

      a = '\0';

      parsing_lcd_gcode = true;

    }

  }

  else if (c == '}' && parsing_lcd_cmd) {        // Closing brace on an LCD command

    parsing_lcd_cmd = false;                    // Unflag and...

    inbound_buffer[inbound_count] = '\0';       // reset before processing

    inbound_count = 0;   

    process_lcd_command(inbound_buffer);        // Handle the LCD command

  }

  else if (c == '\n' && parsing_lcd_gcode){

    parsing_lcd_gcode = false;

    inbound_buffer[inbound_count] = '\0';       // reset before processing

    inbound_count = 0;   

    queue.enqueue_one_now(inbound_buffer);      // Handle the G-code command

  }

  else if (inbound_count < MAX_CURLY_COMMAND - 2){

    if (parsing_lcd_cmd){

      inbound_buffer[inbound_count++] = c;        // Buffer only if space remains

    }

    else

    {

      inbound_buffer[inbound_count++] = b;

    }

    

  }

}

One more thing I forgot, would not work without it:

// now drain commands...

    while (LCD_SERIAL.available()) {

      parse_lcd_byte((byte)LCD_SERIAL.read());  //& 0x7F

Interesting. I’m not sure why it’s throwing away the high bit. But then, which character(s) over 0x80 is it looking for?

Anyway, I’ve applied the change to Marlin, so it will be in 2.0.6.

It is actually bit strange to my likings. The high bit as far as my understanding goes indicates curly bracket command (7 bits only) and it opens up to 8 bits only when GCode enclosed in \n\r"gcode"\n\r.

This is my understanding but I could be wrong. The stuff I need to work works so can not be too far out.

I would like to get some help to get the USB going I am not able to find out what is going on with it.
and maybe way to upload gcode over WIFI (not very important cause it is too slow anyway.)

And one more question/ request doing this “queue.enqueue_one_now(inbound_buffer);” actually stops the machine. Example if I want to send M106 during the print stops the print. What is the better way to sneak G or in this case M into the gcode file execution midprint ofcourse.

thanks

@ivankravets — Basically, if you download Marlin 2.0 on Windows, put it somewhere deep in a folder hierarchy so the absolute path length is very long, and then try to build it, you should get the issue. In various Marlin support forums the advice being given is to move Marlin to the root of C: and try again. AFAIK these users are running recent-ish versions of PIO.

1 Like

In Marlin you can’t call all queue methods from all points in the code with equal freedom. You can block all day inside of a G-code handler with a loop calling idle(), and all it does is suspend G-code processing. But outside of that context it’s a good idea to avoid blocking.

If the position in the queue for M106 doesn’t matter you can just use queue.inject(inbound_buffer) to have your command executed “asap.” This is relatively safe for M106 since the new fan speed doesn’t take effect until the next G0/G1/G2/G3/G5 command (already in the queue) gets processed. If precise timing is needed for M106 then other strategies may be possible.

thanks @thinkyhead isn’t it supposed to be inject_P ? I have tried that but …

I had another great thought to process Gcode sent over wifi properly (not like I do at the moment) how would I tap into queue.get_available_commands(); from extui_malyan_lcd?

I know it is bit amateurish question but I can not think of any better way to put it?

I have done this:
in Configugation.h:
#define SERIAL_PORT_2 1

in ext_ui_malyan_lcd.cpp:

void parse_lcd_byte(byte b) {
  static bool parsing_lcd_cmd = false;
  static char inbound_buffer[MAX_CURLY_COMMAND];
  char c;

  c = b & 0x7F;

  if (!parsing_lcd_cmd) {
    if ( c == '{' ) {                       // A line-ending or opening brace
      parsing_lcd_cmd = true;               // Brace opens an LCD command
    }
    else if ( c == '\r' ) {
      queue.get_available_commands();
    }
  }

  else if (c == '}' && parsing_lcd_cmd) {        // Closing brace on an LCD command
    parsing_lcd_cmd = false;                    // Unflag and...
    inbound_buffer[inbound_count] = '\0';       // reset before processing
    inbound_count = 0;   
    process_lcd_command(inbound_buffer);        // Handle the LCD command
  }
  else if (inbound_count < MAX_CURLY_COMMAND - 2){
    if (parsing_lcd_cmd){
      inbound_buffer[inbound_count++] = c;        // Buffer only if space remains
    }   
  }
}

and yeah, it does process g commands correctly if I use malyan web ui BUT if I use Repetier it does this:

22:58:29.912 : ok
22:58:29.933 : N1 M110*34
22:58:29.933 : N2 M115*36
22:58:29.947 : Error:Line Number is not Last Line Number+1, Last Line: 0
22:58:29.958 : N3 T0*57
22:58:29.958 : N4 M105*35
22:58:29.958 : N5 M114*34
22:58:29.958 : N6 M111 S6*97
22:58:29.959 : N7 T0*61
22:58:29.959 : N8 M20*25
22:58:29.959 : N9 M80*18
22:58:29.974 : Resend: 1
22:58:29.981 : N10 M105*22
22:58:29.987 : ok
22:58:29.987 : echo:Unknown command: ""
22:58:29.987 : ok
22:58:29.987 : Resend: N1 M110*34
22:58:29.987 : Resend: N2 M115*36
22:58:29.987 : Resend: N3 T0*57
22:58:29.987 : Resend: N4 M105*35
22:58:29.987 : Resend: N5 M114*34
22:58:29.987 : Resend: N6 M111 S6*97
22:58:29.987 : Resend: N7 T0*61
22:58:29.987 : Resend: N8 M20*25
22:58:29.987 : Resend: N9 M80*18
22:58:29.987 : Resend: N10 M105*22
22:58:33.039 : N11 M105*23
22:58:42.847 : ok

and disconnects.
Injecting G into running print like I wanted to inject M106 works treat now.
Actually I am not sure if get_available_commands() is the most correct way about it.

So the status as of today of my fight with M200:

  • Marlin2.0 bugfix works treat running G from SD card
  • I can control it over the web UI
    What I still can not crack is:
  • USB interface still no go (I would really appreciate any help with this one from one of you big brains out there since USB seems to be above my pay grade :slight_smile:
  • Repetier connection over TCP/IP (WIFI) not working at all (ready for suggestions)

I am thinking I should start another thread about my journey to get M200 working the way I want it. Did not think it would blow out of propotions this way.

ta ta

Would workspace_dir=C:\Marlin in the platformio.ini fix that, or is that a bit too much of a kludge of a fix workaround?

1 Like

Hi guys, Why if my platform_packages is tool-stm32duino it compiles with framework-arduinoststm32-maple ?

Ask the Marlin developers who wrote that line there at their repo Issues · MarlinFirmware/Marlin · GitHub.