DFU download bugchecks on linux after upgrade to ver 0.0.7

[gulweb]

Global variables use 2616 bytes of dynamic memory.

• WeAct Studio Official Link
• taobao: weactstudio.taobao.com
• aliexpress: weactstudio.aliexpress.com
• blog: www.weact-tc.cn
  /home/webjorn/.arduino15/packages/WeActStudio/tools/Artery_ISP_Console/0.0.1

---

Artery ISP Programmer V3.0.01
Support USART and DFU

DFU Connect......
Device: AT32F403ACGU7 Flash: 1024 KB
PID: 70050347 BID: 4703 Version: 3.2
Device connected Successfully

/home/webjorn/.arduino15/packages/WeActStudio/tools/Artery_ISP_Console/0.0.1/DFU_download.sh: line 12: 135907 Segmentation fault (core dumped) $(dirname $0)/AT32_ISP_Console -dfu -d --fn "$1" --v --o -r
Upload Quit.
Have a good day!

[WeActStudio]

What code did you compile?

[c---]

I'm seeing the same issue. Seems like possibly a bug in AT32_ISP_Console with certain code? Serial.printf() seems to trigger it possibly. I don't know, I wish Artery would give us source code so we can find where the problem actually is.

I'm running latest Arch Linux and have not tested other Linux distros to determine if it could possibly be an issue with bleeding edge libraries or something.

Code:

void setup() {
  Serial.begin(2000000);
}

void loop() {
  Serial.printf("test");
}

Stack trace:

Thread 1 "AT32_ISP_Consol" received signal SIGSEGV, Segmentation fault.
__memcpy_avx_unaligned_erms () at ../sysdeps/x86_64/multiarch/memmove-vec-unaligned-erms.S:273
273		VMOVU	(%rsi), %VEC(0)
(gdb) bt
#0  __memcpy_avx_unaligned_erms () at ../sysdeps/x86_64/multiarch/memmove-vec-unaligned-erms.S:273
#1  0x00007ffff7c09b4c in memcpy (__len=388, __src=<optimized out>, __dest=<optimized out>) at /usr/include/x86_64-linux-gnu/bits/string3.h:53
#2  CImage::FilterImageForOperation (this=0x751d50, pMapping=<optimized out>, Operation=Operation@entry=2, bTruncateLeadFF=<optimized out>) at Image.cpp:1292
#3  0x00007ffff7c040c1 in FILES_FilterImageForOperation (Handle=<optimized out>, pMapping=<optimized out>, Operation=Operation@entry=2, 
    bTruncateLeadFFForUpgrade=<optimized out>) at Files.cpp:89
#4  0x00000000004239a2 in CProgramFile::Open (this=this@entry=0x7fffffffdc40, strPath="./test2.hex", obDevice=obDevice@entry=0x6d5af0) at CFiles.cpp:237
#5  0x000000000041c31e in DownloadFileAndAddressCheck (fileName="./test2.hex", downlaodAddress=downlaodAddress@entry=134217728, 
    m_obBootLoader=m_obBootLoader@entry=0x6d72e0) at main.cpp:1789
#6  0x000000000041c878 in Download (argc=6, argv=argv@entry=0x7fffffffe0a0, arg_index=@0x7fffffffdeac: 5, erasedFlag=erasedFlag@entry=false, 
    m_obCCom=0x6d7d40) at main.cpp:778
#7  0x0000000000407cae in main (argc=6, argv=0x7fffffffe0a0) at main.cpp:2108

Note:
As a workaround you can use objcopy to copy the generated *.hex to binary then AT32_ISP_Console can successfully flash the binary. For example:

$ arm-none-eabi-objcopy -Iihex -Obinary /tmp/arduino_whatever/ouput.ino.hex binary.bin
$ AT32_ISP_Console -dfu -d --fn binary.bin --v --o -r

[c---]

After more investigation it seems to be a problem with any of the formatting functions.

void setup() {
}

void loop() {
  char buf[32] = {0};
  sscanf(buf, " ");
  //strtok(buf, " ");  // This breaks too
}

Same problem, won't flash because ISP Console crashes. When I get time I'll look at the generated hex file to see if I can determine what might be pulled in there that causes the crash. It seems like it might be some sort of parsing bug in ISP Console.

Edit:
Using strtok() makes it crash too. I don't know what is happening.

[c---]

I can't find any particular thing that is causing this. I don't think it's the format function or strtok in particular. It seems to be unrelated to that but those large code inclusions do seem to make it worse. It's somewhat random in nature.

On some machines it crashes every time and on others sometimes it works and sometimes it crashes. This seems more and more likely there is some sort of buffer overrun or other memory corruption in the ISP Console or one of the libraries it uses.

See attached file for the list of possible corruption problems.
ispconsole-errors.txt

[ShaggyDog18]

I experience same issue as described it the case above, I guess, after the attempt of using Serial.printf() in the code...
I am in Windows Arduino IDE 2.0.3 environment.
So, now, as a workaround, I upload .hex by Export Compiled Binary and then by Artery ISP Programmer which is tedious...

P.S. de-installation of AT32 environment in Arduino IDE and re-install resolves the issue... (until the next use of printf() )...

[gulweb]

same problem with 0.0.8
/home/webjorn/.arduino15/packages/WeActStudio/tools/Artery_ISP_Console/0.0.1/DFU_download.sh: line 13: 175194 Segmentation fault (core dumped) $(dirname $0)/AT32_ISP_Console -dfu -d --fn "$1" --v --o -r
Upload Quit.

[c---]

$ AT32_ISP_Console -dfu -d --fn /crash.hex --v --o -r
------------------------------------------------------------
Artery ISP Programmer V3.0.06
Support USART and DFU
------------------------------------------------------------

DFU Connect......
Device:  AT32F403ACGU7    Flash:  1024 KB
PID:  70050347      BID:  4703    Version:  3.2
Device connected Successfully

Segmentation fault (core dumped)

Here is an example hex file that crashes or at least creates a bunch of memory errors in valgrind:
https://github.com/c---/artery-testing/blob/main/crash.hex

Is there any way to report this to Artery? New versions come out but this is still buggy.

[WeActStudio]

https://github.com/ArteryTek

[gulweb]

Still the , same problem.

Some more hints:

When plugging the AT32F403A black pill into USB it becomes impossible to access the serial loader. To be able to program this device, I need to power it from a power pack, since if the bootloader senses USB, a DFU device is created. However, the Artery DFU bootloader crashes when used. The only way to program is to unplug the pill from USB, connect it with serial, plug into power bank while pressing boot0, and then serially program. To test, the reverse procedure must be used,
to get access to console for debug....

Gullik