Youyue 858D+ some reverse engineering + custom firmware

[Gixy]

Excellent! Let me know how to pay for one of these boards. Congrats.

[ApplePi]

Really neat project I'll have to check this out on my 858D+

[lberezy]

wguibas, thank you again for all your help with this.

Do you think it's worth setting up a little wiki page somewhere (maybe madworm might consider using the github wiki) to document all the different 858D configurations out there and what's known working?

[wguibas]

Do you think it's worth setting up a little wiki page somewhere (maybe madworm might consider using the github wiki) to document all the different 858D configurations out there and what's known working?

Sounds like a good idea, I know madworm has a page that decribes the project and has links to this thread for the adapter boards. 


On another note, we need to get ahead of this RST/reboot problem.  I have a dozen chips on my bench and most of them RST/reboot at some point, mostly outside of the main heating routine.   Some reset immediately and some only at the end of the CRA DLE display, or during FAN TST.  It is definitely related to the watchdog timer, because if you disable it in the code, the chip doesn't reset or reboot.  Of my current chips I don't know if any are genuine or chinese/ebay sourced.  I'm not even sure of the one I sent to Iberezy is genuine, but it seemed to work fine here in my machine.  I have 3 machines and they all work fine, so I forgot about the RST problems I initially had, but now working on these machines again with the new adapter, the atmega8 chip,  and iberezy's machine it is rearing its ugly head again.  I just placed an order with mouser for more chips and will label them genuine and try to see if any of them reset too.  The chips that reset seem to do it more frequently in places of the code with big delays.  I don't know if there is a problem with the internal watchdog oscillator in these chips or the whole watchdog timer itself.  I ordered 28, so we will see if they reset at all and have some confidence that this is a counterfeit/bad sourced problem or just luck of the chip.

[Jetiman]

I have the same problem RST. Two ATmega328P tested. One from an Arduino Uno and the other from Reichelt. Both show during cold start RST.

After fast on / off it works.

Youyue 858D+ V6.0  - Firmware 1.43

[wguibas]

So I got my 28 chips from mouser today.  I marked them and numbered them.  The first chip #1 was programmed with correct fuses and hex file.  Put in 858D+ Kaleep and it worked like a charm.  10 Seconds from switch on to ---.  No RST, no 1.43 reappearing.  Chip #1 was happy.  I thought it is the counterfeit chips.  Then 1 tried chip number 2.  It was not as good.  It seemed to run the FanTest and the 1.43 quickly blinked once then repeated the FanTest and then displayed ---.  It took about 16 seconds to get to ---.  So Chip #2 was not as happy as chip #1.  Chip #3 was even more upset as it displayed 1.43 and then immediately went to RST almost everytime I turned the machine on.  I stopped at chip #3.  Playing with the code and chip #2, the chip was definitely rebooting during the 3 second FANTEST delay.  Disabling the watchdog option, the chip works fine.  Re-enabling the watchdog option and it fails.  If you look at the code, the watchdog_on doesn't even happen yet in the code to be triggered?  So I added a watchdog_off at the beginning of the code, which it should be off at this point anyway and all works fine for both chips 2 and 3.   I don't know where the problem lies because some chips work without any change and the ones that don't work, fail differently.  With the change added the unit will still reach a RST if the watchdog timer tripped in the main heating loop, MADWORM turns the watchdog timer on after all the setup, Tested it, RST displays if a delay is added in the main loop greater than 120us. So I apologize to china for now.  Sorry China. 

[madworm]

The watchdog_off you added should not be necessary, this is already done by watchdog_off_early, which runs way before the whole c- runtime stuff. See the header file. I will check the assembler output and see what is actually in there, just to make sure this function wasn't optimised out.

[madworm]

Code: [Select]

youyue858d.cpp.elf:     file format elf32-avr                                                                                                                                       
                                                                                                                                                                                   
                                                                                                                                                                                   
Disassembly of section .text:                                                                                                                                                       
                                                                                                                                                                                   
00000000 <__vectors>:                                                                                                                                                               
       0:       0c 94 3b 00     jmp     0x76    ; 0x76 <_Z18watchdog_off_earlyv>
       4:       0c 94 67 00     jmp     0xce    ; 0xce <__bad_interrupt>
       8:       0c 94 67 00     jmp     0xce    ; 0xce <__bad_interrupt>
       c:       0c 94 67 00     jmp     0xce    ; 0xce <__bad_interrupt>
      10:       0c 94 67 00     jmp     0xce    ; 0xce <__bad_interrupt>
      14:       0c 94 67 00     jmp     0xce    ; 0xce <__bad_interrupt>
      18:       0c 94 67 00     jmp     0xce    ; 0xce <__bad_interrupt>
      1c:       0c 94 67 00     jmp     0xce    ; 0xce <__bad_interrupt>
      20:       0c 94 67 00     jmp     0xce    ; 0xce <__bad_interrupt>
      24:       0c 94 67 00     jmp     0xce    ; 0xce <__bad_interrupt>
      28:       0c 94 67 00     jmp     0xce    ; 0xce <__bad_interrupt>
      2c:       0c 94 84 02     jmp     0x508   ; 0x508 <__vector_11>
      30:       0c 94 0f 02     jmp     0x41e   ; 0x41e <__vector_12>
      34:       0c 94 67 00     jmp     0xce    ; 0xce <__bad_interrupt>
      38:       0c 94 67 00     jmp     0xce    ; 0xce <__bad_interrupt>
      3c:       0c 94 67 00     jmp     0xce    ; 0xce <__bad_interrupt>
      40:       0c 94 ef 08     jmp     0x11de  ; 0x11de <__vector_16>
      44:       0c 94 67 00     jmp     0xce    ; 0xce <__bad_interrupt>
      48:       0c 94 67 00     jmp     0xce    ; 0xce <__bad_interrupt>
      4c:       0c 94 67 00     jmp     0xce    ; 0xce <__bad_interrupt>
      50:       0c 94 67 00     jmp     0xce    ; 0xce <__bad_interrupt>
      54:       0c 94 67 00     jmp     0xce    ; 0xce <__bad_interrupt>
      58:       0c 94 67 00     jmp     0xce    ; 0xce <__bad_interrupt>
      5c:       0c 94 67 00     jmp     0xce    ; 0xce <__bad_interrupt>
      60:       0c 94 67 00     jmp     0xce    ; 0xce <__bad_interrupt>
      64:       0c 94 67 00     jmp     0xce    ; 0xce <__bad_interrupt>
      68:       40 02           muls    r20, r16
      6a:       34 02           muls    r19, r20
      6c:       36 02           muls    r19, r22
      6e:       38 02           muls    r19, r24
      70:       3a 02           muls    r19, r26
      72:       3c 02           muls    r19, r28
      74:       3e 02           muls    r19, r30

00000076 <_Z18watchdog_off_earlyv>:
      76:       a8 95           wdr
      78:       84 b7           in      r24, 0x34       ; 52
      7a:       80 93 f0 01     sts     0x01F0, r24
      7e:       84 b7           in      r24, 0x34       ; 52
      80:       87 7f           andi    r24, 0xF7       ; 247
      82:       84 bf           out     0x34, r24       ; 52
      84:       88 e1           ldi     r24, 0x18       ; 24
      86:       0f b6           in      r0, 0x3f        ; 63
      88:       f8 94           cli
      8a:       80 93 60 00     sts     0x0060, r24
      8e:       10 92 60 00     sts     0x0060, r1
      92:       0f be           out     0x3f, r0        ; 63
      94:       11 24           eor     r1, r1
      96:       1f be           out     0x3f, r1        ; 63
      98:       cf ef           ldi     r28, 0xFF       ; 255
      9a:       d8 e0           ldi     r29, 0x08       ; 8
      9c:       de bf           out     0x3e, r29       ; 62
      9e:       cd bf           out     0x3d, r28       ; 61

I've compiled and checked the assembler source code. As you can see, the reset vector points to "watchdog_off_early". So the watchdog is automatically turned off, every time the chip resets. Later it is turned on only after the setup stuff is over (unless it has previously fired --> error message).

Yet another option to possibly fix this might be to increase the watchdog timeout to 250MS

Code: [Select]

WDTO_250MS
There is some DEBUG code in the main loop to find out how long it actually takes. 120ms should suffice.

If we assume that the chips are OK & the power supply is stable and clean, one possibility is oscillator drift. The internal RC oscillators are very temperature dependent. It might be interesting to shoot a good and a bad chip with a hair-dryer and ice-spray to introduce a frequency drift, which might upset the watchdog timeout. This should old matter much, if the main loop takes close to 120ms to run, but I guess it should be much faster.

I might check the timing tomorrow, if I can find an Arduino board ;-)

[wguibas]

I tried increasing the timer all the way up to 2 seconds and it still changes nothing.  The timer shouldn't even be on and it's not always a watchdog reset, but a chip reboot.  Either way adding the off command at the beginning of the program or disabling the watchdog all together eliminates the problem it seems so far.  As you can see these are genuine atmel chips from mouser.com and the first 3 behave differently from each other with the same hex file and fuse bits.   I have no explanation especially since the chips are behaving differently in a bad way.

[madworm]

I don't understand how turning the watchdog timer off 2x should change anything. The watchdog timer is already off when your addition runs.

...thinking...

OK. I think I have found the error. I've released version 1.44 which should be fixed and NOT require any changes with regards to the watchdog timer.

The issue is as follows:

The code provided by avr-libc that turns off the watchdog timer (see previous assembler code) requires that register R1 (zero-reg) is ZERO. This is usually the case, but not when said code is put into the memory section ".init1". The intention for that was to have the code run as early as possible.

Code: [Select]

      8a:       80 93 60 00     sts     0x0060, r24
      8e:       10 92 60 00     sts     0x0060, r1
      92:       0f be           out     0x3f, r0        ; 63
      94:       11 24           eor     r1, r1

As you can see, in line #2 it writes R1 to 0x0060 (watch dog control register) - assuming that R1 is zero (which is not the case yet). R1 is zeroed in line #4.

I've now put the watchdog_off_early into ".init3", which comes after R1 being zeroed. It should work now.

Code: [Select]

Youyue-858D-plus.elf:     file format elf32-avr


Disassembly of section .text:

00000000 <__vectors>:
       0:       0c 94 3b 00     jmp     0x76    ; 0x76 <__ctors_end>
       4:       0c 94 67 00     jmp     0xce    ; 0xce <__bad_interrupt>
       8:       0c 94 67 00     jmp     0xce    ; 0xce <__bad_interrupt>
       c:       0c 94 67 00     jmp     0xce    ; 0xce <__bad_interrupt>
      10:       0c 94 67 00     jmp     0xce    ; 0xce <__bad_interrupt>
      14:       0c 94 67 00     jmp     0xce    ; 0xce <__bad_interrupt>
      18:       0c 94 67 00     jmp     0xce    ; 0xce <__bad_interrupt>
      1c:       0c 94 67 00     jmp     0xce    ; 0xce <__bad_interrupt>
      20:       0c 94 67 00     jmp     0xce    ; 0xce <__bad_interrupt>
      24:       0c 94 67 00     jmp     0xce    ; 0xce <__bad_interrupt>
      28:       0c 94 67 00     jmp     0xce    ; 0xce <__bad_interrupt>
      2c:       0c 94 84 02     jmp     0x508   ; 0x508 <__vector_11>
      30:       0c 94 0f 02     jmp     0x41e   ; 0x41e <__vector_12>
      34:       0c 94 67 00     jmp     0xce    ; 0xce <__bad_interrupt>
      38:       0c 94 67 00     jmp     0xce    ; 0xce <__bad_interrupt>
      3c:       0c 94 67 00     jmp     0xce    ; 0xce <__bad_interrupt>
      40:       0c 94 ce 08     jmp     0x119c  ; 0x119c <__vector_16>
      44:       0c 94 67 00     jmp     0xce    ; 0xce <__bad_interrupt>
      48:       0c 94 67 00     jmp     0xce    ; 0xce <__bad_interrupt>
      4c:       0c 94 67 00     jmp     0xce    ; 0xce <__bad_interrupt>
      50:       0c 94 67 00     jmp     0xce    ; 0xce <__bad_interrupt>
      54:       0c 94 67 00     jmp     0xce    ; 0xce <__bad_interrupt>
      58:       0c 94 67 00     jmp     0xce    ; 0xce <__bad_interrupt>
      5c:       0c 94 67 00     jmp     0xce    ; 0xce <__bad_interrupt>
      60:       0c 94 67 00     jmp     0xce    ; 0xce <__bad_interrupt>
      64:       0c 94 67 00     jmp     0xce    ; 0xce <__bad_interrupt>
      68:       40 02           muls    r20, r16
      6a:       34 02           muls    r19, r20
      6c:       36 02           muls    r19, r22
      6e:       38 02           muls    r19, r24
      70:       3a 02           muls    r19, r26
      72:       3c 02           muls    r19, r28
      74:       3e 02           muls    r19, r30

00000076 <__ctors_end>:
      76:       11 24           eor     r1, r1
      78:       1f be           out     0x3f, r1        ; 63
      7a:       cf ef           ldi     r28, 0xFF       ; 255
      7c:       d8 e0           ldi     r29, 0x08       ; 8
      7e:       de bf           out     0x3e, r29       ; 62
      80:       cd bf           out     0x3d, r28       ; 61

00000082 <_Z18watchdog_off_earlyv>:
      82:       a8 95           wdr
      84:       84 b7           in      r24, 0x34       ; 52
      86:       80 93 f0 01     sts     0x01F0, r24
      8a:       84 b7           in      r24, 0x34       ; 52
      8c:       87 7f           andi    r24, 0xF7       ; 247
      8e:       84 bf           out     0x34, r24       ; 52
      90:       88 e1           ldi     r24, 0x18       ; 24
      92:       0f b6           in      r0, 0x3f        ; 63
      94:       f8 94           cli
      96:       80 93 60 00     sts     0x0060, r24
      9a:       10 92 60 00     sts     0x0060, r1
      9e:       0f be           out     0x3f, r0        ; 63


Please get V1.44 and test :-)

[wguibas]

I'm at work now,  I'll test it tomorrow.   thank you

[Gixy]

 

[Gixy]

This shows that it's still useful to know assembly language and system's architecture. At least for micro-controllers. I personnally prefer to program directly in assembly, but I'm an old style guy now :-(
I think that 90% of today's Arduino users wouldn't be able to find such a bug.

[wguibas]

I loaded your new firmware on my worst chip and it works fine.  Glad we could get this figured out and hopefully things will be a lot more stable for everyone now.   Thanks again.  I'll upload some compiled 1.44 hex files for the Samsung and MK1841D3 boards soon.

 On a separate note,  I guess I adjusted the FANSPD upper and lower thresholds in the old  .h file because I did get a FAN SPD error with the POT turned all the way down.  My FAN SPD range with the adapter boards and voltage divider goes from 140 to ~385 so I had changed the .h file to 130 to 390 and all is well again, so anyone with my adapter boards will need to adjust those if your compiling yourself.

[bitseeker]

Thanks, madworm, for tracking down the issue and posting the details. It's been a while since I've done assembler (though it was x86 at the time) and it's cool to see even if for a different processor.

[wguibas]

Version 1.44 Hex files for the adapter board chips.

[Gixy]

Hi Wayne,
You have a PM

[GiantGnome]

wguibas (Wayne?), The resets are not due to a lack of a pull-up resistor to the AVR's reset pin? I can't seem to find it on your adapter board, and as far as I can see, reset only connects to the ISP. App note AVR042 recommends a 10K pull-up resistor in noisy environments.

Sorry if this has been discussed before. I've just received my Kaleep 858d+, and randomly stumbled over this thread.

[wguibas]

wguibas (Wayne?), The resets are not due to a lack of a pull-up resistor to the AVR's reset pin? I can't seem to find it on your adapter board, and as far as I can see, reset only connects to the ISP. App note AVR042 recommends a 10K pull-up resistor in noisy environments.

I thought that might be the problem too, but jumpering the ICSP header with a 10K resistor between RST and 5V made no difference. I have implemented a resistor in future board files, but I have so many already made without it, probably 30 of each board, that a new version will never be produced.  A resistor can always be bodged on the underside of the board for good measure, but for now it doesn't seem to be an issue.

The problem lied in the firmware putting watchdog_off_early at init1 instead of init3 as Madworm has fixed in his firmware version 1.44.

I did find this obscure reference in the AVR notes referring to the problem being an issue with programming in C code.

http://www.atmel.com/webdoc/AVRLibcReferenceManual/FAQ_1faq_startup.html

[/quote]

How to modify MCUCR or WDTCR early?

... Note that in C code, any such function would preferably be placed into section .init3 as the code in .init2 ensures the internal register __zero_reg__ is already cleared.

[wguibas]

On another note, I'm getting requests for the board to put in 220V machines.  Someone needs to test the temp output and make sure at double my 110V that the output isn't much higher than what I've calibrated here.  If it's wrong, the handle could easily go up in smoke, setting the temp to 300 and the output goes to 500+.  .  You would need a thermocoupler like on a fluke 87V  and I would say set the temp to 100-150 and see what comes out the tip.   If it's 300 when set to 150 than an adjustment needs to be made to the firmware or my code change removed.  If it's close than proceed higher and test at 200-250 etc.  Better safe than sorry.

[wguibas]

Also attached are the board files for the MK1841D3.  Gerbers and Sprint Layout 6 file.

 

[GiantGnome]

On another note, I'm getting requests for the board to put in 220V machines.  Someone needs to test the temp output and make sure at double my 110V that the output isn't much higher than what I've calibrated here.  If it's wrong, the handle could easily go up in smoke, setting the temp to 300 and the output goes to 500+.  .  You would need a thermocoupler like on a fluke 87V  and I would say set the temp to 100-150 and see what comes out the tip.   If it's 300 when set to 150 than an adjustment needs to be made to the firmware or my code change removed.  If it's close than proceed higher and test at 200-250 etc.  Better safe than sorry.

I have a 220V version. I have laid out and ordered a clone of your board, modified to use of the pile of TQFP32 versions of the Atmega328p I have lying around. It is away at OSH Park, but it will probably take about a month to get to me, and there is always a chance I have messed up the connections.

[JHammer]

I will get a 220V version of a MK1841D3 machine in the next days, I've ordered a board from Wayne (@Wayne: Thanks to your great support!) and I have a Fluke with a thermocoupler in my shop. So as soons as Waynes board arrives, probably in one or two weeks, I will start some measurements and post my results.

[wguibas]

OK cool. Thank you

[Gixy]

So I'll do. I already have the Kaleep, just wait for the Wayne's board ordered tonight :-)
I can also compare before/after modification as I did a complete measurement table before mod.