Back
[08:52:43] <AllinYourhead> Howdy!
[08:52:56] <woodyj21> howdy
[08:55:40] <AllinYourhead> I have issues with two MCU's, one AVR 32-bit master and a 8-bit ATmega slave. The master controls RESET pin of slave for ISP purpose, however the slave is in control of the power regulator to the master. When the master is switched off the reset pin ends up around 1.5V range (0-3.1V system) and the slave is then in undefined signal state and sometimes locked in reset
[08:56:05] <AllinYourhead> circuit is GPIO of Master -> 1k resistor to 8-bit and 10k pullup on slave side
[08:57:28] <AllinYourhead> any easy solution without adding more hardware?
[11:46:41] <Jartza> whee-o
[11:47:08] <Jartza> "The factory has started work on your boards."
[11:47:12] <Jartza> \o/
[11:53:24] <CoolBear> Hurray!
[12:21:58] <Getty> Jartza: do you check it now again, or do you wait for surprise? ;-)
[12:23:40] <CoolBear> This one comes to mind:
http://xkcd.com/281/
[12:29:13] <Jartza> Getty: nope, didn't check it anymore, I already did etch the layout and assemble a board and it worked :)
[12:29:32] <Jartza> and got a lot of good and productive feedback from #hackvana about the different revisions of the board
[12:29:40] <Getty> Jartza: ah! ok thats good
[12:29:47] <Jartza> I'm just exited, now all I can do is wait
[12:29:51] <Jartza> but I suck in waiting :D
[12:29:57] <Getty> we all do
[12:31:21] <Jartza> https://www.dropbox.com/s/93tq3xywdifpeft/20140813_009.jpg
[12:31:57] <Jartza> well, I can enhance and better the software while waiting
[12:32:34] <Jartza> oh, that's not the last etch
[12:32:41] <Jartza> maybe I didn't take a picture of it
[12:32:43] <Jartza> oh well
[13:12:32] <Tom_itx> Jartza is that etch or machined?
[13:13:46] <Jartza> etch
[13:14:51] <Tom_itx> toner transfer or UV mask?
[13:14:57] <Jartza> toner
[13:15:10] <Tom_itx> pretty clean
[13:15:17] <N1njaneer> Jartza: Looks good!
[13:15:21] <Jartza> yeah, my modded laminator works nicely
[13:15:28] <Jartza> with pulsar toner transfer paper
[13:15:39] <Jartza> didn't even bother to put the toner reactive foil on top of that
[13:15:46] <Tom_itx> it takes just the righ combination of paper & heat to get it right
[13:16:07] <Jartza> http://www.biltema.fi/fi/Toimisto---Tekniikka/Toimistotarvikkeet/Koneet/Laminointikone-24841/
[13:16:10] <Jartza> bought that one
[13:16:18] <Jartza> it had 120°C and 145°C thermostats
[13:16:27] <N1njaneer> Need the direct laser structuring, where the UV laser literally vaporizes the copper off in real-time. Those things are insanely awesome to watch work.
[13:16:33] <Tom_itx> i used a clothes iron
[13:16:40] <Jartza> took away the 120°C and replaced that with 145°C, and on place of 145°C I did put 170°C thermostat
[13:17:01] <Jartza> I wanted to use the phaser, but it seems that it's broken
[13:17:07] <Jartza> the one we had in storage
[13:17:12] <N1njaneer> Awwww.
[13:17:38] <Jartza> but I guess the toner transfer is quite ok, doesn't take that long either
[13:18:01] <Tom_itx> i haven't done any in a while
[13:18:09] <N1njaneer> What problem does it have? Sometimes the encoder wheels get gunked up internally and just literally need to be wiped off. I got mine locally from eBay for $70 USD and that was the only problem with it. That and it seems to have a single nozzle clogged which isn't a big deal.
[13:19:03] <Jartza> N1njaneer: I haven't checked more than quickly, but I'm guessing some kind of bigger problem as it doesn't even power up the display
[13:19:10] <Jartza> and doesn't say a word
[13:19:17] <N1njaneer> Hmm, check the fuse :)
[13:19:34] <Jartza> that I was thinking of doing, just been too busy to play with that
[13:19:43] <N1njaneer> And use a beefy power cord!
[13:19:50] <Jartza> that's no problem
[13:20:11] <Jartza> I have a lot of those IEC power cables that have 2.5mm2 wires :)
[13:20:25] <Jartza> from used UPSes
[13:20:34] <N1njaneer> I actually had this cheap-crap Chinese power cord that literally melted and smoked when I used it. The power cable was standard thickness, but it had these rediculous like 22 gauge wires inside the normal-sized cable cladding. It was unbelievable.
[13:20:51] <Jartza> huh
[13:21:01] <Jartza> sounds dangerous
[13:21:08] <N1njaneer> Yeah, though self-fusing :D
[13:22:02] <N1njaneer> Just layed out my first Atmel Cortex M0+ board here, should have it next weekend, and I'll see if I managed to do everything correctly :)
[13:22:23] <Jartza> great
[13:22:30] <Jartza> I started with the attiny85 and lcd :)
[13:23:12] <Jartza> but in the end, after all the nice comments, suggestions and redesigning I'm quite happy with the board
[13:23:33] <Jartza> routes are quite simple and "functional blocks" separated on card
[13:23:50] <N1njaneer> It's a nice looking board!
[13:24:12] <Jartza> power booster is near battery, modem circuit in other end of card, lcd capacitors in the middle and mcu itself near lcd signal pins
[13:25:18] <Jartza> guess I need to practice how to solder with solder paste and hot air station
[13:25:30] <Jartza> and what temperature to use etc.
[13:26:14] <Jartza> N1njaneer: you saw the latest with rounded corners and recess in audio-jack etc? :)
[13:28:36] <Jartza> http://gerblook.org/pcb/nsXDvkENyKr6VuHCyz4afJ
[13:28:38] <Jartza> that one
[13:29:26] <Jartza> oh yeah and thicker power lines, added one cap to power booster in parallel to another and and and...
[13:32:34] <twnqx> yeah, i tend to make my power lines 0.5mm, too
[13:34:03] <Jartza> those are even thicker
[13:34:19] <Jartza> but there was plenty of space
[13:36:15] <Jartza> 0.8mm :)
[13:36:38] <Jartza> and 1.0mm from battery holder to caps
[13:41:18] <mux_> I'm slowly turning insane
[13:41:26] <mux_> is 5 days slowly?
[13:44:20] <N1njaneer> Compared to the accretion of the earth in our solar system 5 days is rather quite quick, though if you measure 5 days in femtoseconds it could seem quite slow.
[13:44:49] <mux_> is there maybe anyone here who is familiar with Dean Camera's LUFA? he's not here today btw
[13:45:31] <mux_> I need somebody to bounce ideas off, basically
[13:45:37] <mux_> because by myself I'm not solving this
[13:50:57] <Jartza> I guess I'm just turning impatient, because the board production "normally" takes 5 working days ;)
[13:51:19] * twnqx knows that feeling
[13:51:40] <Jartza> I'm guessing it's also because this is my first ever factory made pcb
[13:51:55] <twnqx> yeah, that's a big one :)
[14:02:02] <RikusW> mux_: in short what is wrong ?
[14:02:42] <mux_> RikusW: I'm rewriting the mass storage LUFA bootloader
[14:02:42] <mux_> for xmega
[14:03:00] <mux_> and it's not attaching, like, at all
[14:03:27] <mux_> I don't know enough about the inner workings of LUFA to know where to start debugging
[14:03:32] <RikusW> that could mean anyone of a lot of things went wrong
[14:03:38] <mux_> yeah exactly
[14:03:46] <RikusW> enumerating is complicated
[14:04:13] <RikusW> wait for abcminiuser to join..
[14:04:25] <mux_> well I'm pretty sure he's asleep right now
[14:04:39] <mux_> also, I've kind of bothered him a couple times already
[14:04:52] <RikusW> do you have software usb analyzer sw ?
[14:05:09] <RikusW> -sw
[14:05:23] <RikusW> like wireshark ?
[14:05:26] <mux_> nothing that gives me raw packet data, and the software that should give me that doesn't seem to work properly
[14:06:00] <RikusW> does lufa support the xmega yet ?
[14:06:02] <mux_> wireshark could be a last resort, but it needs to run in a VM if I understand correctly
[14:06:04] <mux_> no, it does not
[14:06:14] <mux_> but the mass storage class and usb stuff does
[14:06:22] <mux_> and I've used it for CDC and HID applications before
[14:06:30] <RikusW> on xmega ?
[14:06:32] <mux_> oh also, I'm using Atmel Studio instead of ancient makefiles
[14:06:33] <mux_> yes
[14:07:14] <mux_> basically: I made life hard for myself, and now I'm asking other people to fix stuff for me :P
[14:07:17] <RikusW> I'd check the clock settings in the code
[14:07:25] <mux_> clock is fine
[14:07:28] <mux_> interrupts are fine
[14:08:12] <RikusW> take a working enumeration and compare to the broken one
[14:08:22] <RikusW> (when packet dumping)
[14:08:35] <RikusW> which OS do you use ?
[14:08:36] <mux_> I guess I should get wireshark running
[14:08:38] <mux_> Windows 8.1
[14:09:00] <mux_> as a general rule: if it runs on windows 8.1, it will run on any windows :P it's the hardest by far to get stuff working under
[14:09:09] <mux_> especially let's-cut-some-corners-here-embedded stuff
[14:09:23] <RikusW> wireshark does dump usb in linux after doing modprobe usbmon, not sure about windows
[14:09:38] <mux_> there is a guide on how to get it to work under windows
[14:10:11] * RikusW uses Mint Nadia
[14:10:24] <RikusW> and occasionally reboots to win7
[14:10:37] <RikusW> or use XP in Virtualbox
[14:11:20] <mux_> I do everything in Windows :P
[14:12:10] <mux_> but more importantly; I develop specifically for client systems on Windows... so this has to work
[14:13:08] <RikusW> how about using ASF ?
[14:13:29] <mux_> I've tried, but ASF is such an unreadable mess
[14:13:43] <mux_> I need to hack and modify it anyway to suit my hardware, so I highly doubt that's any easier
[14:13:53] <mux_> and LUFA is a bit better as far as licensing goes
[14:14:05] <mux_> this is going into a commercial application with quite a long lifetime
[14:14:12] <mux_> I don't want Atmel breathing down my neck tbh
[14:14:14] * RikusW haven't used ASF yet, couldn't make sense of it all
[14:14:33] <mux_> they have some very talented ASM programmers at Atmel :P
[14:14:35] <RikusW> I thought ASF was free ???
[14:14:49] <mux_> they're definitely not GPL!
[14:14:53] <mux_> or free free
[14:15:04] * RikusW have written a few thousand lines of AVR asm code so far
[14:16:02] <mux_> I understand the extensive use of asm in these very-often used libraries
[14:16:16] <mux_> but it's so opaque and badly commented
[14:16:44] <mux_> I'd rather have C foundation libraries
[14:17:20] <mux_> and have the freedom of doing compiler optimizations
[14:23:18] <Jartza> ahh
[14:23:25] <Jartza> now I know what I can do while waiting
[14:23:33] <mux_> that was a reboot for usbpcap
[14:23:37] <Jartza> I needed to test if my modem works @1MHz
[14:23:42] <mux_> in case anyone was wondering where I went
[14:24:32] <N1njaneer> ASF is free from Atmel, yes, to use in your applications. I'm not sure specifically what license they have made it avaliable on, but AFAIK it was all written in-house at Atmel so it shouldn't have to be covered by any split-licensing difficulties, etc.
[14:25:20] <Jartza> something to do while waiting for the boards ;)
[14:25:45] <N1njaneer> ASF is kind of a mess, yes, and documentation is a bit slow on catching up so areas are thin, HOWEVER, the fact that you have a lot of working example code and at least SOME documentation is far better than not having either. At very least you can pick through the ASF code to see how things are done.
[14:26:34] <Jartza> hoh, found an old video of the first proto
[14:26:35] <N1njaneer> I've had to do a lot more with a lot less in the past, so even though ASF isn't as awesome as we'd all like it to be (at least at the moment!) it's far, far, FAR better than many other things out there.
[14:26:43] <Jartza> well, old... like, 2 months old or something
[14:26:44] <Jartza> https://www.dropbox.com/sh/8fvwqp5bg0r3nkr/AFetybgb_L#lh:null-VID_20140401_020840.mp4
[14:27:11] <Jartza> that's my "v1"
[14:27:19] <Jartza> if you wonder why the current one was v4
[14:27:41] <Jartza> or actually, that's "v0"
[14:32:43] <mux_> update: wireshark kinda works
[15:46:40] <mux_> god, FTL is hard on hard
[15:57:25] <learath> ... ftl is hard on easy :P
[16:28:01] <t4nk119> Hey
[16:28:12] <t4nk119> I'm back here looking for help with an AVR board
[16:28:15] <t4nk119> Any takers?
[16:28:22] <Roklobsta> nup
[16:28:41] <Roklobsta> shoot anyway
[16:29:43] <Lambda_Aurigae> no takers....we can't help if you don't ask your question.
[16:33:32] <t4nk119> My problem is that I need to be able to remotely restart a system in the (unlikely) event that its software hangs up and does not respond.
[16:34:14] <t4nk119> Effectively, this means that I need to force-reset a Printrboard (at90usb1286)
[16:34:37] <t4nk119> But the printrboard will be installed in a device in the field, so it cannot depend on a user pressing the reset-button.
[16:35:35] <Lambda_Aurigae> why not turn on the watchdog timer?
[16:35:54] <t4nk119> in the event that the printrboard software hangs, I cannot force that.
[16:36:03] <Lambda_Aurigae> with that you just have to reset it every so often in software...if it hangs and the reset doesn't happen then it reboots the chip.
[16:36:08] <N1njaneer> Yes, use the watchdog timer.
[16:36:15] <Lambda_Aurigae> automagic reboot.
[16:36:23] <N1njaneer> Specifically designed to do what you are needing.
[16:37:06] <Lambda_Aurigae> otherwise you will likely need a second microcontroller hooked to usb or network or something that can be remotely accessed and have it tied to the reset pin on the at90usb1286.
[16:37:06] <t4nk119> I need to use a raspberry pi to trigger the restart in software
[16:37:19] <t4nk119> I have a second microcontroller.
[16:37:32] <t4nk119> I'm using a raspberry pi to control it, I hadn't quite gotten to type that yet :P
[16:37:45] <t4nk119> And furthermore, the printrboard needs to run 3
[16:37:52] <t4nk119> 3D* print jobs that can last for hours
[16:38:02] <t4nk119> so periodic restarts for no good reason are not an option
[16:38:05] <Lambda_Aurigae> so use a GPIO on the rPI hooked to the reset pin on the AVR.
[16:38:33] <Lambda_Aurigae> or, fix the avr software so it doesn't hang up.
[16:38:37] <t4nk119> Our cabling is already fixed, and doesn't allow my to wire the reset pin to a GPIO
[16:38:50] <Lambda_Aurigae> then install the psychic reboot unit.
[16:39:00] <t4nk119> is that a joke? :p
[16:39:13] <t4nk119> Have I proposed something impossible?
[16:39:15] <Lambda_Aurigae> because if you can't hook something physically to it there is no way to do it other than using the watchdog.
[16:39:33] <Lambda_Aurigae> if the software hangs, there is no way to get the software to do a reset.
[16:39:59] <Lambda_Aurigae> this isn't a multicore/multitasking PC system you are talking about.
[16:40:23] <t4nk119> No. And I know other AVR boards, like arduinos (ATmega 2560 for example) can be forced to reset and accept new firmware even when the currently running firmware hangs up.
[16:40:28] <Lambda_Aurigae> now, if you are running some kind of timeslice multitasking OS on it, you can have one task play interface for the reboot.
[16:40:55] <t4nk119> That is not an option unfortunately.
[16:40:56] <Lambda_Aurigae> the programmer interface on the arduino pulls the reset pin low and puts it into programming mode.
[16:41:20] <t4nk119> Okay.
[16:41:37] <Lambda_Aurigae> or toggles the reset and pulls another line low or something to signify programming mode.
[16:41:59] <t4nk119> Is it possible that resetting the usb interface on the raspberry pi end could somehow create an exception on the Printrboard end, causing it to restart?
[16:42:03] <Lambda_Aurigae> but either way, to force it into bootloader mode it reboots the chip with the hardware reset.
[16:42:22] <Lambda_Aurigae> if you have the usb software on the chip watching for that, yes.
[16:42:32] <Lambda_Aurigae> but, if that usb software on the chip locks up,,,,no can do.
[16:42:44] <Roklobsta> what is watching the watchdog?
[16:42:50] <Lambda_Aurigae> the watchdog is a timer.
[16:42:54] <Lambda_Aurigae> it starts counting down.
[16:43:00] <Roklobsta> yeah but what if it doesn't work
[16:43:01] <Lambda_Aurigae> when it reaches zero it resets the chip.
[16:43:08] <Lambda_Aurigae> it's a hardware implementation.
[16:43:25] <Lambda_Aurigae> to keep it from resetting constantly, your program has to constantly reset the timer.
[16:43:34] <t4nk119> ohhhhhhhhh
[16:43:35] <t4nk119> so
[16:43:47] <t4nk119> I could set the watchdog to always be on
[16:44:01] <Lambda_Aurigae> so if your program locks up and doesn't get to that reset point, the watchdog timer causes a reset of the entire chip, like a button on the reset pin.
[16:44:01] <t4nk119> but guarantee that any "valid" firmware will reset it periodically
[16:44:07] <Lambda_Aurigae> yes.
[16:44:36] <Roklobsta> in your main code loop make sure you pat the watchdog before the timer gets to zero
[16:44:41] <Lambda_Aurigae> so if your firmware goes into a race condition or hangs up and doesn't get to the main loop to do the watchdog reset every so often, the chip resets.
[16:45:04] <Lambda_Aurigae> so you only get resets if your code is broke...in which case, FIX THE CODE!
[16:45:05] <t4nk119> But some parts of the code are blocking. So to ensure the watchdog gets reset, I should probably use a hardware timer right?
[16:45:24] <Lambda_Aurigae> depends on how long they block for.
[16:45:30] <Roklobsta> if hey block, the main loop won't pat the watchdog in time and the RESET
[16:45:44] <Roklobsta> the watchdog is a hardware timer
[16:46:34] <Roklobsta> you are proposing another watchdog externally which is completely redundant
[16:48:46] <Lambda_Aurigae> looks like it uses a 128KHz oscillator and can have a prescaler of 1 to 1024.
[16:49:45] <t4nk119> Also: this board needs to be able to accept remote firmware updates, via the raspberry pi. So it is conceivable that someone, tasked with writing new firmware, will write bad firmware that hangs (honest mistake, happens often), which means I will have hundreds of devices in the field hanging. I need to be able to fix this problem by subsequently uploading new, non-hanging firmware to my entire fleet of devices, without asking users to h
[16:49:55] <Roklobsta> watchdogs seem only useful in a main loop style system. may be harder to implement in an event driven or task schedulaing system
[16:49:56] <Lambda_Aurigae> so 1/128th of a second...anything blocking longer than that can turn the wdt off temporarily before and turn it on after.
[16:50:33] <Lambda_Aurigae> t4nk119, then you need a gpio hooked to the reset pin.
[16:50:44] <Lambda_Aurigae> or be able to cycle power.
[16:51:08] <Lambda_Aurigae> and on that note, must take wifey out for fooood.
[16:51:23] <Roklobsta> t4nk119: like the rpi, just have a boot loader that runs after reset but never gets overwritten by the main code. if after 5 seconds it doesn't get a magic packet from the rpi run as usual
[16:51:45] <Roklobsta> Lambda_Aurigae: Eat at Joes.
[16:52:27] <t4nk119> That's what I have now, but if the firmware hangs then I have no way to get back to the bootloader
[16:52:38] <Roklobsta> t4nk119: once it's implemented test the crap out of the watchdog/boot process.
[16:53:17] <Roklobsta> but keep it simple. i have had remote embedded systems connected via gprs that we were 1000's of km away we could upload new firmware to.
[16:53:26] <Roklobsta> but it's got to be the most robust part of the system
[16:55:14] <Roklobsta> it had a CF card with firmware images on it. it had a 'safe' version of code and a 'new; version of code. we'd upload new code to the safe file and tell it to reboot and reprogram. if anything went wrong it would reflash the safe version or we could remotely tell it to reflash the safe version.
[16:55:45] <Roklobsta> nono we'd upload new code to the new file and never ever replace the safe version.
[16:56:34] <Roklobsta> testing is important. state machines in your process that can cope with any condition that isn't planned for really help.
[17:10:29] * twnqx hands Roklobsta a "What could possibly go wrong!" sign
[17:13:04] <Roklobsta> stuff does go wrong and you spend $500 sending someone out with a finger to press reset.
[17:14:28] <Roklobsta> like finding out the reason the systems lockup sometimes is because the original programmer didn't read the manual and issue a HALT instruction at the end of the shutdown/reboot function.
[17:16:46] <Roklobsta> instead used a while(1) while the power rail dropped but in this brownout condition the program counter would get a random number in it and the system would start running code from a random place and bring the power rail back up.
[17:17:26] <Roklobsta> which only a manual reset could fix as the watchdog hadn't been implemented.
[17:19:03] <Roklobsta> so RTFM.
[17:19:08] <twnqx> hmmmmm
[17:19:29] <twnqx> excuse me while i read some code
[17:21:15] <twnqx> is there a wrapper to call halt from c? :>
[17:21:38] <Roklobsta> this was on an SILABS 8051 mcu but the principle applies across the board.
[17:22:43] <twnqx> yeah... can't find code on that
[17:25:54] <Roklobsta> the halt/sleep/stop instruction effectively guaranteed the cpu could only start running again if a reset was asserted.
[17:29:45] <twnqx> in theory, with a deep enough sleep mode, avrs will do the same. hmmm
[17:32:08] <Roklobsta> the trouble with that bug was it only happned now and then
[17:41:10] <Roklobsta> but was expensive to fix
