Linux64 upload-reset appears to be a 32 bit binary

All distros
Posts: 808
Joined: Thu Jul 21, 2016 4:24 pm

Re: Linux64 upload-reset appears to be a 32 bit binary

Post by ag123 » Thu Jun 01, 2017 5:17 pm

i'd prefer not to do a static link as the interface between libc or several of the dynamic link libraries to the linux kernel is actually different between different kernel versions. doing a static link can cause it to abort / error out on every other platform the syscall interface is different i think there are quite a lot of changes between the v3 and v4 kernels. and static linking would cause a v4 binary to fail on v3 kernel or a v3 binary to fail on a v4 kernel etc.

while for dynamic linking, those are just symbols and so long as the correct version (normally simply a same or later version) of libc dll is found on the system, it would simply work. while libc deals with the interface between itself and the kernel which can be different on different systems

note that libc and the kernel has tight linkage and that libc and the kernel is normally build in a rather elaborate 'sandboxing' process so that it makes a particular libc works with a particular kernel and all other apps can be dynamically linked to the libc (normally on the major version). and those same apps would work on a different platform / distribution / kernel version as long as the same libc dll version is there
upload-reset sends a 'DTR pulse' on usb-serial and then send the text '1EAF' ... 3-rev5-dfu
The IDE performs this reset automatically by performing a special sequence of changes on the USB serial port:
- Pulse DTR (high and then low, so that you’ve created a negative edge)
- Write “1EAF” in ASCII over the serial pipe.
This will cause Maple to reset. Only the first 4 bytes after a negative edge of DTR are checked for this command, so it’s important you actually create a negative edge, rather than just ensuring DTR is low.
hence running

Code: Select all

>./upload-reset /dev/maple
does exactly that send 'DTR pulse' and send '1EAF'. it should cause the maple mini / blue pill to reset and the led flashes

this means that it would be the same whether you run the command manually or that arduino ide does it.
the rest of the reset is actually done by the sketch itself (in the usb-serial driver routines)
but i think it is quite possible the 'driver codes' may have some 'bug' or that certain cases is not catered

just 2 cents

Posts: 808
Joined: Thu Jul 21, 2016 4:24 pm

Re: Linux64 upload-reset appears to be a 32 bit binary

Post by ag123 » Thu Jun 01, 2017 7:51 pm

in case you are looking for a solution, in the libmaple core: ... l.cpp#L297

Code: Select all

#ifdef SERIAL_USB 
            // Got the magic sequence -> reset, presumably into the bootloader.
            // Return address is wait_reset, but we must set the thumb bit.
            uintptr_t target = (uintptr_t)wait_reset | 0x1;
            asm volatile("mov r0, %[stack_top]      \n\t" // Reset stack
                         "mov sp, r0                \n\t"
                         "mov r0, #1                \n\t"
                         "mov r1, %[target_addr]    \n\t"
			"mov r2, %[cpsr]           \n\t"
you may like to try inserting

Code: Select all

before the asm statement

my guess is this would trigger a *hard system reset*, but i've not tried out the code
it could possibly be a solution, but i've not evaluated if there may be other implications of doing so, e.g. would this cause stm32 to fall into a boot loop? e.g. that some memory contents / registers that's not cleared between resets makes it run the same code and reset over and over again[/s] this won't work the code is already calling

Code: Select all

Last edited by ag123 on Fri Jun 02, 2017 12:33 am, edited 1 time in total.

Posts: 67
Joined: Tue Aug 02, 2016 2:26 am

Re: Linux64 upload-reset appears to be a 32 bit binary

Post by keypunch » Thu Jun 01, 2017 9:12 pm


I will pass on the dynamic vs static linking as you know my reasons and I know why vendors static link code.

I asked what to expect when doing an "upload-reset /dev/maple" from the CLI outside the Arduino IDE because I had mixed behaviour.

1) First time did this via CLI and LED went solid.
2) After pressing "reset" buttom on uC board no LED light.
3) Via Arduino post (2) not good and no LED.
4) After "reset" button on uC and usb power cycle IDE was not successful and is different problem in my opinion that needs new topic for that unique proble,

The upload-reset now works for linux64, but appears there are other issues beyond that will need a new topic.

Where does one find the source for upload-reset?


John L. Males
Toronto, Ontario
01 June 2017 16:36/17:11

Posts: 808
Joined: Thu Jul 21, 2016 4:24 pm

Re: Linux64 upload-reset appears to be a 32 bit binary

Post by ag123 » Thu Jun 01, 2017 10:12 pm

keypunch wrote: Where does one find the source for upload-reset?
in the src folder under tools/linux64 ... load-reset

static linking in this case would be problematic as the static links are with libc. as libc is tightly bound to a particular linux kernel it is bound to, static linking may mean the utility could break on just about every other linux kernel it is run on other than the kernel it is compiled on and with. in this case dynamic linking is possibly the more appropriate means so that it could run on as many platforms / distributions as is possible

the glibc i'm compiling with is GLIBC 2.23
this may seem a little 'old' but it would likely mean it would run on any distributions with glibc 2.23 and higher, this would likely run on any distributions dating back say a year back in 2016 till today and beyond. but i'm not sure if user with glibc older/earlier than 2.23 may find issues running it.

you may want to try the

Code: Select all

patch in the libmaple core on your local copy 2 posts above to see if it helps.
However, short of having more people test that, i'd think we should not include the patch till we are pretty sure there are no other side effects, e.g. the possibility of boot loops. the trouble with system resets is that there would always be some codes / registers that's carried across a reset and it need not be in the place we patch, those can lead to problems that is 'difficult or can't be solved' short of a power cycle. what seem apparent to me in the existing codes is that it jumps to the boot loader codes rather than doing a system reset, the effect is pretty much similar[/s] this won't work the codes is already calling

Code: Select all


Post Reply