Can you provide the traces from chipload.
Also, can you program your custom board using the SDK/Windows ?
I'm not sure how much testing has been done with Chipload on Linux.
Yes, SDK on Windows works fine, and also it works fine on 32-bit Linux and on other version of 64-bit Linux. So it looks to be a subtle timing issue with ChipLoad. There is nothing more in the log, just these two lines:
ChipLoad: ../nptl/pthread_mutex_lock.c:80: __pthread_mutex_lock: Assertion `mutex->__data.__owner == 0' failed.
Aborted (core dumped)
I also managed to get a core dump (attached). Backtrace is the following:
Core was generated by `Tools/ChipLoad/Linux32/ChipLoad -BLUETOOLMODE -PORT /dev/ttyUSB0 -BAUDRATE 1152'.
Program terminated with signal SIGABRT, Aborted.
#0 0x55577430 in __kernel_vsyscall ()
#0 0x55577430 in __kernel_vsyscall ()
#1 0x55733607 in raise () from /lib/i386-linux-gnu/libc.so.6
#2 0x55736a33 in abort () from /lib/i386-linux-gnu/libc.so.6
#3 0x5572c757 in ?? () from /lib/i386-linux-gnu/libc.so.6
#4 0x5572c807 in __assert_fail () from /lib/i386-linux-gnu/libc.so.6
#5 0x555a513f in pthread_mutex_lock () from /lib/i386-linux-gnu/libpthread.so.0
#6 0x080553b4 in ?? ()
#7 0x08056976 in ?? ()
#8 0x080555c0 in ?? ()
#9 0x555a2f70 in start_thread () from /lib/i386-linux-gnu/libpthread.so.0
#10 0x557f150e in clone () from /lib/i386-linux-gnu/libc.so.6
The full command for ChipLoad invocation was the following:
Tools/ChipLoad/Linux32/ChipLoad -BLUETOOLMODE -PORT /dev/ttyUSB0 -BAUDRATE 115200 -MINIDRIVER Platforms/BCM920736TAG_Q32/uart_DISABLE_EEPROM_WP_PIN1.hex -BTP Platforms/BCM920736TAG_Q32/20736_EEPROM.btp -CONFIG build/hello_sensor-BCM920736TAG_Q32-rom-ram-Wiced-release/hello_sensor-BCM920736TAG_Q32-rom-ram-Wiced-release.hex -CHECKCRC -NOVERIFY -DLMINIDRIVERCHUNKSIZE 251
core.zip 68.7 K
How often can you reproduce this ? why do you feel its timing related issue ? Is this issue seen only using your custom board and not our dev kit board ? If you could share details related to your custom board as a private message we could look to see if there is something different in the design that's causing the download failure.
PS: You have answered to a couple questions I've asked. Just want to confirm once again.
How often can you reproduce this ? ---> Always with our board.
why do you feel its timing related issue ? ---> Because of mutexes Well, it just a guess, don't take it seriously.
Is this issue seen only using your custom board and not our dev kit board ? ---> yes
Not sure what details you need about our board. AFAIK, debug UART port connection scheme on our board is the same as on dev board (I'm a SW guy). Anyway, you have the backtrace and core dump. It should give a lot of info for the developers. They can create a custom binary with fixes or additional debug traces and give me for a try.
thnx for your responses, working with developers to help you solve this issue.
As per previous conversation , our test engineers did not see any issue on the 64 bit Linux machine using our Tag03. Since you are having an issue to switch back and forth from 32 to 64 bit. Would suggest you to re install the SDK and try compiling the application on your 64 bit machine.. Let us know if you resolve it.
I tried it again with my existing SDK and now it sometimes crashes, sometimes not! So it definitely is a timing issue (race condition) in your ChipLoad application.
I suggest your developers to try Ubuntu 64bit 14.01.01
Why you ask me?
You should fix it, not me.
You are correct. I was confused.
We are waiting for next release of the WICED Smart SDK to verify the Linux installer for x32/x64.
The Linux64 CGS and ChipLoad binaries in 2.2.1 appear to be identical to the 2.2.0 versions.
userc_8120 is right. Both 32bit and 64bit Linux binaries of ChipLoad tool are binary equal between 2.2.0 and 2.2.1 SDKs. This tool does not dynamically link any other SDK libraries which could affect the behaviour, so there is simply no chance that new SDK 2.2.1 fixes the crash of ChipLoad tool.
It is the same tool basically. No changes were made at all.