STC15L2K60S2 about stcdude

[nekromant]

What's the output? I just programmed the very same STC12C5A60S2 with stcdude last week with no problems

[midnight-wonderer]

@blindman2k I can confirm successfully connection to that certain device. Double check your connection especially when you are using a breadboard. You can also tap the uart output for better visualization for what going on.

[nekromant]

Try also different handshake baudrates. These tend to be messy on some crystals

[blindman2k]

Hey guys and thanks for the quick responses. I have a fully formed PCB not a breadboard and I have a full debug trace of stc-isp for Windows running and it's flawless, both at 2400 and 115200 every time.
https://www.dropbox.com/s/72hx4ptwfk1f39o/program%20short.log (ignore my comments and snips).

I am getting a checksum error and a segfault at both 2400 and 115200.
Is there a debug/trace flag?

STC ISP Tool. (c) Necromant 2012
Loading lua script: /usr/local/share/stcdude/lua/init.lua
Using /dev/cu.usbserial-A703BXNC @ 115200
Power on target MCU at will
Checksum error, dropping packet!
Segmentation fault: 11

[nekromant]

What OS are you running?

[blindman2k]

Mac, latest version.

[nekromant]

I haven't tested stcdude on mac, so this might be the problem by itself. I'll give a code a quick look to see what could have segfaulted. Meanwhile, can you compile it with -g and use gdb to get a backtrace?
I can't reproduce this myself, since I don't have a mac around (and am too lazy to install hackintosh).

[blindman2k]

I have no issue with laziness :)
I am stuck until Monday as I am not in the office and the hardware is.

[blindman2k]

gdb dump is below.

(gdb) run -p /dev/cu.usbserial-A703BXNC -b 115200:115200 -f ~/Downloads/20141222-master-stc15-02.hex

STC ISP Tool. (c) Necromant 2012
Loading lua script: /usr/local/share/stcdude/lua/init.lua
Using /dev/cu.usbserial-A703BXNC @ 115200
Power on target MCU at will
Checksum error, dropping packet!

Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_INVALID_ADDRESS at address: 0x0000000000000008
parse_info_packet (L=0x100104c20, pck=0x0, baudrate=115200) at payload.c:183
183     struct info_packet *inf = (struct info_packet *) pck->data;

The backtrace is ...

(gdb) backtrace
#0  parse_info_packet (L=0x100104c20, pck=0x0, baudrate=115200) at payload.c:183
#1  0x0000000100001a41 in l_mcu_connect (L=0x100104c20) at stcdude.c:219
#2  0x000000010000cec8 in luaD_precall ()
#3  0x0000000100017b22 in luaV_execute ()
#4  0x000000010000d1c3 in luaD_call ()
#5  0x0000000100009bbc in lua_callk ()
#6  0x000000010001a9c5 in luaB_dofile ()
#7  0x000000010000cec8 in luaD_precall ()
#8  0x0000000100017b22 in luaV_execute ()
#9  0x000000010000d1c3 in luaD_call ()
#10 0x000000010000ca1c in luaD_rawrunprotected ()
#11 0x000000010000d5b0 in luaD_pcall ()
#12 0x0000000100009c4f in lua_pcallk ()
#13 0x0000000100001d0b in main (argc=1068064, argv=0x100104c20) at stcdude.c:321

[blindman2k]

Hey Nekro,

Did that assist you at all. I am under a bit of pressure to get this completed. I just realised I put in the wrong serial number. It is an STC15L2K60S2 and I have updated the subject to reflect this.

/me slaps himself.

[nekromant]

Sorry for the delay, I couldn't find a spare minute to have a close look at it.
It looks like it doesn't handle things properly if a packet with an invalid checksum arrives during negotiation phase. This should be fixed now. See if it works. But if STC15L uses different checksumming - well, we're screwed and more reverse-engineering is needed.

[blindman2k]

Yep, it doesn't crash now. It just responds "Checksum error, dropping packet!"
Thanks for your effort, it is appreciated.

[nekromant]

See if the other 'stc-isp' tool works for you, If it does - I'll see if I can add some functionality from it. It's hard to do anything without the actual device on your bench.

[blindman2k]

Yep, I am working with them too. The most promising is
https://github.com/grigorig/stcgal which has specific support for the STC15
protocol but doesn't quite work.