-
#225 Reply
Posted by
Gixy
on 01 Mar, 2016 06:20
-
Excellent! Let me know how to pay for one of these boards. Congrats.
-
#226 Reply
Posted by
ApplePi
on 01 Mar, 2016 07:20
-
Really neat project I'll have to check this out on my 858D+
-
#227 Reply
Posted by
lberezy
on 01 Mar, 2016 11:58
-
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?
-
#228 Reply
Posted by
wguibas
on 01 Mar, 2016 12:40
-
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.
-
#229 Reply
Posted by
Jetiman
on 02 Mar, 2016 13:13
-
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
-
#230 Reply
Posted by
wguibas
on 04 Mar, 2016 21:11
-
-
#231 Reply
Posted by
madworm
on 04 Mar, 2016 21:58
-
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.
-
#232 Reply
Posted by
madworm
on 04 Mar, 2016 22:44
-
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
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 ;-)
-
#233 Reply
Posted by
wguibas
on 04 Mar, 2016 22:58
-
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.
-
#234 Reply
Posted by
madworm
on 05 Mar, 2016 00:20
-
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.
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.
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 :-)
-
#235 Reply
Posted by
wguibas
on 05 Mar, 2016 06:07
-
I'm at work now, I'll test it tomorrow. thank you
-
#236 Reply
Posted by
Gixy
on 05 Mar, 2016 08:51
-
-
#237 Reply
Posted by
Gixy
on 05 Mar, 2016 09:08
-
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.
-
#238 Reply
Posted by
wguibas
on 05 Mar, 2016 13:26
-
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.
-
#239 Reply
Posted by
bitseeker
on 05 Mar, 2016 14:24
-
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.
-
#240 Reply
Posted by
wguibas
on 05 Mar, 2016 19:24
-
Version 1.44 Hex files for the adapter board chips.
-
#241 Reply
Posted by
Gixy
on 06 Mar, 2016 10:25
-
Hi Wayne,
You have a PM
-
#242 Reply
Posted by
GiantGnome
on 06 Mar, 2016 17:32
-
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.
-
#243 Reply
Posted by
wguibas
on 06 Mar, 2016 18:30
-
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.
-
#244 Reply
Posted by
wguibas
on 06 Mar, 2016 19:57
-
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.
-
#245 Reply
Posted by
wguibas
on 06 Mar, 2016 20:18
-
Also attached are the board files for the MK1841D3. Gerbers and Sprint Layout 6 file.
-
#246 Reply
Posted by
GiantGnome
on 06 Mar, 2016 21:56
-
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.
-
#247 Reply
Posted by
JHammer
on 06 Mar, 2016 22:43
-
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.
-
#248 Reply
Posted by
wguibas
on 06 Mar, 2016 22:45
-
OK cool. Thank you
-
#249 Reply
Posted by
Gixy
on 06 Mar, 2016 22:53
-
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.