Back
[06:57:05] <OndraSter> this is some very silent channel
[07:00:46] <ok9swl> OndraSter: silence is golden
[07:01:28] <OndraSter> no
[07:01:36] <ok9swl> All are busy working, or busy studying or maybe busy doing nothing, hi.
[07:01:37] <OndraSter> golden ingot is gold
[07:01:42] <OndraSter> hi
[07:01:43] <tobbor> OndraSter! like, totally tell us about the project!
[07:01:49] <OndraSter> lol
[07:01:54] <OndraSter> I thought he stopped saying that
[07:06:41] <bitd> End of the world be nigh arduino peoples <.<
[07:08:30] <ok9swl> bitd: Please, do not call us arduino people, many of us can design our own boards :)
[07:08:51] <OndraSter> some of us even design arduino boards!
[07:08:53] <OndraSter> lol
[07:08:58] <bitd> Damnit, wrong channel.
[07:09:02] <bitd> >.>
[07:09:14] <ok9swl> OndraSter: lol
[07:10:42] <bitd> Even that has to go wrong today.
[07:12:58] <ok9swl> bitd: Don't worry, I am only joking
[08:35:06] <philfine_> Hello everyone
[08:36:08] <philfine_> I am currently using with little success a DIY MkI JTAG as debugger to a atmega64
[08:36:41] <philfine_> Which debugger would you recommend as a substituter to this crap one :D
[08:37:16] <philfine_> I mean board would you recommend. Mostly interested to use it with avr-gdb
[08:38:26] <OndraSter> Dragon if you are cheap ($49) or JTAGICE 3 ($99)
[08:38:35] <OndraSter> Dragon supports more chips, but has zero protection
[08:39:18] <philfine_> What o you mean by protection?
[08:39:21] <philfine_> do
[08:39:33] <philfine_> Burns easily
[08:42:23] <tzanger> good morning. I'm using avr-libc with pretty good success, but I'm finding considerable trouble with using printf()
[08:42:55] <tzanger> I'm using Peter Fleury's excellent uart library and wiring up stdin/out to it
[08:42:58] <philfine_> OndraSter: ?
[08:43:32] <OndraSter> by protection I mean proper output/input transistors, same for USB
[08:43:50] <OndraSter> it is easy to overdrive and kill supposedly
[08:43:52] <tzanger> printf("some string"); works. printf("var is %d", some_int); works. however printf("var1/2 is %d,%d", some_int1, some_int2); seems to reset the chip
[08:43:54] <OndraSter> I haven't managed to do it yet
[08:44:14] <tzanger> my UART FIFO sizes are 128 bytes each, plenty of room
[08:45:19] <philfine_> Now a wild guess
[08:45:36] <philfine_> Maybe you use too much ram and the stack hits the heap
[08:46:23] <philfine_> tzanger: That guess was for you :)
[08:46:28] <tzanger> philfine_: not a bad guess, but I don't think that's the case
[08:46:41] <philfine_> Ok
[08:46:51] <tzanger> philfine_: because breaking the printf() into two should make the stack usage the same as the "print 1 var" that works
[08:47:04] <tzanger> philfine_: gonna try something, moment
[08:47:06] <philfine_> not really
[08:47:36] <philfine_> I assume printf calls other functions so it is not necessarily the same
[08:47:55] <philfine_> As it will have to push both ints into stack plus many other things
[08:48:07] <tzanger> right
[08:48:31] <tzanger> but printf("%d,%d", i1, i2); will consume more stack than printf("%d", i1); printf("%d", i2);
[08:48:44] <philfine_> Yes
[08:48:58] <philfine_> At least one more int of stack :D
[08:49:00] <tzanger> and hte latter (two one-var printfs) will consume the same stack as one one-var printf
[08:49:09] <philfine_> Don't know about the actual implementation
[08:49:28] <philfine_> The second version also fails ?
[08:49:40] <philfine_> The 2 printf's fail ?
[08:51:24] <tzanger> yes, the second version fails
[08:51:43] <tzanger> which it should not if stack were an issue (barring some stupid leak)
[08:51:57] <tzanger> sprintf() also fails, which leads me ot think it's in the vsprintf stuff
[08:52:55] <philfine_> It should not be the stack then
[08:52:57] <philfine_> :D
[08:54:17] <tzanger> :-)
[09:12:47] <tzanger> hm
[09:13:01] <tzanger> can gdb's "info registers' be trusted with avarice?
[09:13:17] <tzanger> it's showing me after I hit a breakpoint that SP is 0
[09:13:39] <tzanger> PC is right but all registers (r0-r31, SREG and SP are 0)
[09:24:34] <tzanger> yeah I am pretty sure it's not a memory issue unless stdio is doing something goofy with malloc
[09:25:00] <tzanger> this device has 4K of RAM, I've got a whopping 0x20b bytes of bss and the rest is for stack and heap
[09:47:06] <tzanger> definitely something with the serial routines, when I disable them I regain normal operation
[09:47:50] <tzanger> and definitely something with stdio... if I use Fleury's uart_puts() it still works
[10:01:36] <philfine_> Is there an open source ICE MKI ave code available ?
[10:01:42] <philfine_> avr
[10:07:17] <tzanger> not sure, I was thinking along similar lines
[10:07:38] <tzanger> I did find this a while back, not sure how it compares to mk1 or devices which look like MK1 like AVR-JTAG-USB
[10:07:52] <tzanger> http://vak.ru/doku.php/proj/bitbang/bitbang-jtag
[10:21:41] <devilsadvocate> Can anyone help with peter fleury's bootloader on the mega32? It seems to be compiling fine, but avrdude isnt able to connect using stk500v2. The led seems to be glowing, though, as per the button state, with some strange caveats
[10:22:58] <devilsadvocate> Or point me to a bootloader thats known to work with the m32 without too much prodding?
[10:32:08] <philfine_> Are there any cheaper reliable debuggers than dragon, chinese or so ?
[10:35:44] <tzanger> philfine_: avr-jtag-usb is pretty cheap, but as I mentioned, if that ft232 circuit is correct that's probablyt he cheapest
[10:38:47] <tzanger> hm, using stdio seems to just break things. it works fine on a smaller program, but this one is nowhere near the resource limits and it crashes
[10:39:17] <tzanger> MCUSR doesn't show any reset cause when it happens, but MCUSR does show the correct bits for powerup or reset button
[10:51:00] <philfine_> tzanger: what exactly is happening when you debug the code ?
[10:51:12] <tzanger> well
[10:51:17] <philfine_> I mean in the breaking call
[10:51:35] <tzanger> I have an ISR that fires off 1ms interrupts, this is code I've used on a dozen projects and works fine
[10:51:55] <tzanger> every 5s or so I printf() and the printf seems to reset the mcu
[10:51:59] <tzanger> if I use puts, same thing
[10:52:15] <tzanger> if I use uart_puts (Fleury's code, bypassing stdio) it works
[10:52:23] <philfine_> Do you have watchdogs of some type ?
[10:52:27] <tzanger> sprintf() does the same, meaning it has nothing to do with stdio but rather with libc
[10:52:31] <tzanger> no watchdogs
[10:52:58] <philfine_> Is it somehow related to the int variables ?
[10:53:02] <tzanger> but to test that I also inserted a clrwdt() in the main loop
[10:53:07] <philfine_> I mean if you put simple strings the same happens ?
[10:53:08] <tzanger> no, it crashes now just printing strings
[10:53:18] <tzanger> i.e. printf("foo");
[10:53:28] <tzanger> puts("foo") does the same now
[10:53:40] <tzanger> uart_puts("foo"); works fine
[10:53:45] <philfine_> It is getting worst :D
[10:54:06] <philfine_> ??
[10:54:06] <tzanger> also, itoa()/uart_puts() works fine (that's how I'm printing USCSR)
[10:54:35] <tzanger> no, it seems very strongly related to code generation
[10:54:39] <tzanger> I usualy use -O0
[10:54:45] <tzanger> soI tried -O1 and the problem changed
[10:54:51] <tzanger> then I tried -Os and it changed again
[10:55:03] <tzanger> but going back to -O0 did not recreate -O0's original problem
[10:55:17] <tzanger> and by now the code's changed so much I can't really retest anyway so I'm just moving forward
[10:55:26] <tzanger> avr-size says my static RAM usage is a whopping 380 bytes
[10:55:32] <philfine_> Do a -fdump-tree-final to get the code after optimisations passes of GCC and see how it expands printf :)
[10:55:40] <tzanger> and I bet 350 of those are just the UART buffers
[10:56:22] <philfine_> It will pretty-print GCC's IR just "before" generating assembly
[10:56:32] <tzanger> interesting
[10:56:37] <tzanger> I'll give that a shot
[10:56:43] <philfine_> GCC developer here :D
[11:20:41] <tzanger> oh balls
[11:20:53] <tzanger> I had the goddamned stdio setup commented out
[11:37:00] <tzanger> interesting
[11:37:09] <tzanger> I found a hack function to print dynamic RAM use
[11:37:14] <tzanger> nothing going on with printf() etc
[11:37:22] <tzanger> the dynamic ram use stays steady (and lots of room)
[11:37:34] <tzanger> http://stackoverflow.com/questions/960389/how-can-i-visualise-the-memory-sram-usage-of-an-avr-program
[11:37:40] <tzanger> the freeRam() function
[11:38:36] <mog> tzanger, thanks for that
[11:38:44] <tzanger> yeah it's interesting
[11:38:51] <tzanger> doesn't solve *my* problem
[11:38:52] <tzanger> but yeah
[11:39:13] <mog> i had that problem 12 months ago
[11:39:23] <mog> but fixed it by rebalancing some sutff
[11:39:26] <mog> er stuff
[11:39:29] <mog> but couldnt confirm it
[11:39:36] <mog> happens again i will be able to now
[11:52:47] <philfine_> tzanger: Any news on the printf problem
[11:53:00] <philfine_> Did generating the dumps turned out into something ?