Open gulweb opened 2 years ago
What code did you compile?
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
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.
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
I experience same issue as described it the case above, I guess, after the attempt of usingSerial.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() )...
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.
$ 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.
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
Global variables use 2616 bytes of dynamic memory.
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!