Back
[11:50:21] <gorroth> ali1234: the code didn't always wait for SPM to be free
[11:50:33] <gorroth> that is all
[11:50:50] <ali1234> ah, of corse
[11:51:48] <gorroth> it still doesn't jump to the app for whatever reason, but i'll debug that tonight
[11:52:11] <gorroth> but the app i know is there, since avrdude can confirm it
[12:10:26] <dlm> Has anyone added custom metadata to the Avro file header? If so, can you provide an example?
[12:12:40] <_abc_> Hello. Been trying to refresh my knowledge. avr like 328 can be programmed (flashed) fine with 3.3V Vdd right?
[12:13:51] <gorroth> looks like it can be
[12:15:11] <gorroth> basically, i don't know why any of them can't be flashed inside their normal electrical characteristics
[12:15:17] <_abc_> I remember it so but now I have to know and the info is buried somewhere in the 600+ page pdf
[12:15:27] <gorroth> 328 is just a bigger 48/88/168; so, it will work
[12:15:30] <_abc_> yes
[12:15:38] <_abc_> also 90usb162 ?
[12:15:48] <gorroth> i never used that one
[12:15:54] <gorroth> the datasheets can tell you
[12:24:57] <ali1234> there is a thing called high voltage programming
[12:25:11] <ali1234> but it's only required if you messed up the fuses
[12:25:32] <ali1234> and it needs a special programmer
[12:25:35] <_abc_> I know.
[12:26:52] <LeoNerd> Or if you want to do other weird things like debugWire
[12:27:07] <LeoNerd> Or disable RSTEN
[12:31:30] <Jartza> evening
[12:33:34] <Jartza> https://github.com/Jartza/attiny85-vga/blob/master/vgafont.dat
[12:33:41] <Jartza> https://github.com/Jartza/attiny85-vga/blob/master/vgafont.py
[12:33:52] <Jartza> I added those so anyone can have their own font to VGA :)
[12:35:41] <_abc_> Is there a nice intro to using SAM-BA on linux?
[12:35:49] <_abc_> I see it appears as a CDC driver?
[12:37:34] <Jartza> http://www.atmel.com/images/atmel-42328-using-sam-ba-for-linux-on-sama5d3-xplained_training-manual_an8995.pdf
[12:44:57] <_abc_> thanks
[12:45:06] <_abc_> Damn search engines constantly trying to sell me something
[12:47:10] <gorroth> search engines are one of the only things that work on me when it comes to online ads
[12:50:24] <_abc_> I am somewhat new to this. How does the presence of SAM-BA affect code security? I understand that the JP5-TST trick will rewrite SAM-BA into flash. Are security bits erased in the process? The rest of the flash too?
[12:50:42] <gorroth> oh derp; i know why it won't load my app. i put the app onto flash, but i never got it loaded into ram
[12:50:53] <gorroth> so wehn i jump to the address, it probably has 0xff bytes there or something
[12:50:56] <gorroth> derp derp
[12:51:03] <LeoNerd> AVRs execute directly out of flash
[12:51:53] <gorroth> so jumping to address 0 should start running code at flash address 0?
[12:52:56] <_abc_> Everyone refers to "Standard Boot Strategies" from SAMA5D3 data sheet -- nobody finds the datasheet?
[12:54:17] <_abc_> A5D3 is ARM v5 <something> v3?
[12:55:34] <_abc_> http://media.digikey.com/pdf/Data%20Sheets/Atmel%20PDFs/SAMA5D3_Series.pdf $deity atmel people, FIX YOUR SEARCH ENGINE
[12:56:15] <gorroth> LeoNerd: typedef void APP(void); ((APP*)0)(); // should jump to the app at flash address 0x0000 then, right?
[12:56:53] <LeoNerd> I've no idea. That looks odd
[12:57:37] <gorroth> anyway, my question is basically that if i jump to an address, will it be an address on flash?
[12:58:14] <LeoNerd> Mmm?
[12:58:21] <LeoNerd> AVRs are Harvard architecture
[12:58:38] <gorroth> so if i jump to address 0, will it be reading from flash?
[12:58:45] <LeoNerd> Addresses in the program address space are in flash yes, because that's the only kind of memory in the program space
[12:58:52] <gorroth> okay
[12:58:56] <LeoNerd> Addresses in the data space will not be in flash, because the flash isn't accessible from data space
[12:59:01] <LeoNerd> "address 0" is not a thing
[12:59:07] <LeoNerd> "address 0 in the program space" is a thing; and that's on the flash
[12:59:31] <gorroth> i know the difference in the spaces
[12:59:41] <gorroth> but i'm trying to figure out if that code iwll jump to the code on flash
[13:00:01] <gorroth> n/m. i'll just read its assembly
[13:00:42] <_abc_> http://www.atmel.com/Images/Atmel-6500-32-bit-Cortex-M3-Microcontroller-SAM3S4-SAM3S2-SAM3S1_Datasheet.pdf this pdf wants a password?!
[13:09:21] <averowsky> I changed fuse bits but I think something is not right. I would like speed up my atmega 328p to 16mhz. What is the best way to check if it is realy working with 16mhz
[13:09:21] <averowsky> ?
[13:10:50] <averowsky> 16Mhz means that every iteration in loop should be run every 0,000000063s ?
[13:11:04] <LeoNerd> Make one of the PWM outputs output a known frequency and probe it with a freq. meter
[13:11:47] <averowsky> LeoNerd: dont have freq meter
[13:11:48] <LeoNerd> I'd perhaps suggest making it count to 7 with no prescale; thus every 8 CPU ticks it flips state.. two flips makes one complete cycle, so 16 CPU ticks. Therefore, 1MHz
[13:11:55] <LeoNerd> Ah, then that could be trickier
[13:12:23] <LeoNerd> Apply enough prescale + count that it should blink once per second and see if an LED matches a clock?
[13:12:39] <averowsky> Can I print it with UART ?
[13:12:45] <averowsky> doesnt matter yes ?
[13:15:39] <averowsky> LeoNerd: Please tell me If this is irght
[13:15:49] <averowsky> f = Fclk / (2 * prescaler * (1 + OCR0A))
[13:16:03] <averowsky> 1÷(16000000÷(2×"64"×(1+255))) = 0,002048 ~ 2ms CS01 CS00
[13:16:22] <averowsky> So every 2ms counter will be increased
[13:16:43] <averowsky> looks right ?
[13:22:20] <RafiX> hi
[13:23:05] <averowsky> It looks like it is working with 8Mhz :?
[13:23:06] <averowsky> :/
[13:23:09] <averowsky> tested with LED
[13:24:09] <LeoNerd> Don't forget that depending on PWM mode, when the counter overflows it might toggle the output state
[13:24:20] <LeoNerd> So it requires two overflows per complete ON/OFF cycle
[13:26:55] <averowsky> LeoNerd: I choose CTC and interrupt on overflow. So as far as I understand every 2ms interrupt will be trigerred yes ?
[13:29:45] <_abc_> Okay, I think I got the hang of SAM-BA
[13:30:05] <_abc_> Has anyone written some 'open source' programming tool using SAM-BA boot loader?
[13:30:23] <gorroth> averowsky: 10 MHz means that each clock cycle is 1/10 of a microsecond
[13:31:19] <gorroth> oh, you said 16, not 10... can't read
[13:31:23] <gorroth> but replace 1/10 with 1/16
[13:32:09] <Jartza> or each clock cycle is 62.5 nanoseconds
[13:32:41] <Jartza> but hmm.
[13:33:02] <averowsky> gorroth: yyyyy it is not 1/16000000 ?
[13:33:19] <averowsky> (1/16000000)s
[13:37:13] <averowsky> its the same :)
[13:47:51] <averowsky> If External 16Mhz Crystal is connected it has to work with 16 Mhz ?
[13:54:12] <aandrew> averowsky: what else would it work at?
[13:54:39] <aandrew> that's assuming no dividers
[13:55:48] <averowsky> aandrew: So I again set a fuse bits to be sure there is no divider but at the end avrdude ask me about:
[13:55:58] <gorroth> true. i can't math
[13:56:06] <averowsky> avrdude: safemode: efuse changed! Was ff, and is now 7
[13:56:21] <aandrew> averowsky: what is the full avrdude line you're using and for what device
[13:56:46] <averowsky> aandrew: avrdude -cusbasp -pm328p -U lfuse:w:0xff:m -U hfuse:w:0xd9:m -U efuse:w:0xff:m
[13:56:51] <averowsky> atmega328p
[13:58:58] <aandrew> hm
[13:59:05] <aandrew> I can't see a reason why it's warning you
[13:59:29] <aandrew> anyone else? got it configured for external crystal, no divide by 8, reset is not disabled, SPI is not disabled...
[13:59:43] <aandrew> I at first thought you were disabling reset but you're not
[14:00:12] <aandrew> ah
[14:00:16] <aandrew> set efuse ot 0x07
[14:00:20] <aandrew> you're setting undefined bits
[14:00:57] <averowsky> Ok, works
[14:01:12] <averowsky> this is was what I get from one of the generators from website
[14:02:34] <averowsky> aandrew: but my LED is still not blinking with appropriate freq
[14:03:35] <aandrew> the only generator you should use is the avr fuse calculator that is the top result on google. :-)
[14:03:41] <aandrew> averowsky: ok, what's your code look like
[14:03:45] <aandrew> pastebin.com it
[14:03:55] <averowsky> aandrew: I simplified it maximaly
[14:04:17] <Jartza> what generator?
[14:04:20] <Jartza> ahh
[14:04:42] <Jartza> http://avrcalc.pl/
[14:04:48] <Jartza> I find that to be most up-to-date
[14:04:51] <Jartza> and has more chips
[14:05:14] <aandrew> I use
http://www.engbedded.com/fusecalc/
[14:05:43] <Jartza> I used to
[14:05:47] <averowsky> http://pastebin.com/PUnncvDW
[14:05:51] <averowsky> aandrew:
http://pastebin.com/PUnncvDW
[14:05:52] <Jartza> but it doesn't seem to be up to date
[14:06:20] <aandrew> Jartza: I don't often need the very latest device
[14:06:28] <Jartza> me neither, but I needed attiny841
[14:06:45] <aandrew> averowsky: unless you know what instructions are being run you will never get accurate timing that way
[14:07:04] <aandrew> gcc -O0 vs -Os will have different blink times
[14:07:39] <aandrew> I'd set up a timer with a 1msec overflow and either use interrupts or manually watch the timer overflow flag to do your counting
[14:08:06] <averowsky> aandrew: I tried it and it also didnt work
[14:08:40] <averowsky> aandrew: This is code is minimalistic to not fuck up anything :)
[14:08:59] <aandrew> you're in a technical form. Please don't use terms like "didn't work" without being clear. it's not very helpful and we can't help you if you can't give us useful information to work from
[14:09:22] <averowsky> aandrew: Ok. So you advise to use it with timer ?
[14:09:50] <aandrew> I would, yes
[14:10:24] <averowsky> aandrew: I got 0s in Makefile
[14:10:31] <Jartza> if you want precise time, use timer.
[14:10:57] <Jartza> admitted, timers can be intimidating in the beginning, but trust me, it's very useful to learn them
[14:12:38] <aandrew> averowsky:
http://pastebin.com/JQssrr5P is from a working project
[14:13:08] <aandrew> and that construct (set up a 1msec timer, set flags and execute subsystem loops bases on the flags) is the heart of almost every one of my embedded systems
[14:13:20] <aandrew> there are two big advantages in my mind
[14:14:14] <aandrew> 1) you can set up "hierarchies" where you can then write lean/fast and fat/slow code as needed and 2) you don't ever "back up" the system if a function takes longer than you thought. you instead "skip" a tick
[14:15:16] <aandrew> in the few cases where I needed very accurate timing I had fractional counters which would push the msec counter ahead an extra count every 4 ticks (or whatever) since the timer interrupt would be 960us instead of 1000us (for example)
[14:15:46] <aandrew> that code uses modulus which is a dumb way to do it
[14:15:55] <aandrew> the faster/better way is to count to 100 and reset to zero
[14:15:59] <aandrew> instead of an expensive divide operation
[14:16:26] <averowsky> aandrew: This is my code
http://pastebin.com/RybUvd3J
[14:16:55] <averowsky> It looks like it is 8Mhz
[14:17:06] <averowsky> Im looking at your link now.
[14:17:11] <aandrew> http://pastebin.com/ng6eJ2bu
[14:17:12] <aandrew> like that
[14:25:57] <averowsky> aandrew: it doesnt go into any condition ten_ms_flag or hundred_ms_flag
[14:43:45] <gorroth> so i put my bootloader on my atmega168, and then i use it to write my application starting at flash address 0x0000. avrdude is able to confirm the program is on the device, but my bootloader using something like: asm volatile ("ijmp" :: "z" (0x0000)); doesn't start the app. going back to avrdude and changing the efuse so it boots to the app, however, does get the app running
[14:43:59] <gorroth> what could i be doing wrong with the jump to 0x0000?
[14:45:14] <aandrew> averowsky: so debug. set the LED on on the ISR so you verify the interrupt is firing
[14:47:54] <averowsky> aandrew: it is not being fired
[14:48:04] <averowsky> I tried to turn on the led but it doesnt work
[14:49:24] <ali1234> counter needs to be volatile
[14:50:11] <aandrew> averowsky: ok. verify the settings of the timer regs. that code is for at90 not atmega328
[14:53:37] <averowsky> ali1234: Thanks
[14:55:03] <averowsky> aandrew: Had to change to TCCR0B
[14:59:40] <averowsky> aandrew: 100 times in hundred_ms_flag body gives me 10 s
[14:59:42] <averowsky> thanks
[15:17:43] <Jartza> hmm
[15:17:51] <Jartza> how about now?
https://github.com/Jartza/attiny85-vga/blob/master/vgafont.dat
[15:18:10] <Jartza> could that be nice way to define font? :)
[15:18:21] <Jartza> should not be too hard format
[15:19:26] <gorroth> god, i have no idea why my bootloader won't jump to the program it has at flash address 0x0000. avrdude confirms that the app is there
[15:19:41] <inkjetunito> Jartza: how about binary literals?
[15:19:41] <gorroth> and when i reset the BOOTRST fuse so that it goes to app section instead of bootloader, it runs the app i uploaded
[15:20:09] <gorroth> typedef void (*App)(void); App app = 0x0000; app(); // should get me to app at 0x0000, right?
[15:20:11] <Jartza> inkjetunito: I find them less readable
[15:20:38] <inkjetunito> oh. looks like binary literals are in c++14, not in 11
[15:21:05] <gorroth> am i missing something?
[15:21:31] <Jartza> well I'm now using C nor C++ either with this
[15:21:43] <Jartza> the code is assembly
[15:22:45] <gorroth> it seems like jumping to that address is causing my AVR to reset, and then it just pops right back to the bootloader
[15:24:05] <inkjetunito> Jartza: oh. ok. the dots and xs are well readable, but the file itself isn't very well machine readable.. or does it use fixed line numbers for the data?
[15:25:15] <kristoiv> Hello everyone! I have an frustrating problem. If I call the sei();-command (enable global interrupts), not having any interrupts enabled though, my code stops working because initialization of variables (to constant source-code values; 0x00) stops working. Assembly shows that it just reuses whatever it finds in R1. Story of problem (+ assembly / debug scrndumps):
http://www.avrfreaks.net/forum/interrupts-leads-constants-memory-corr
[15:25:29] <Jartza> inkjetunito: oh, it's very machine readable ;)
[15:25:51] <Jartza> inkjetunito:
https://github.com/Jartza/attiny85-vga/blob/master/vgafont.py this parses it into this
https://github.com/Jartza/attiny85-vga/blob/master/font.inc
[15:26:56] <inkjetunito> Jartza: ok, so the tools are there already :)
[15:28:55] <Jartza> yea
[15:28:59] <Jartza> and it's quite free-form
[15:29:06] <Jartza> comments accepted almost anywhere
[15:30:28] <Jartza> ...without specific need to tell they are comments
[15:31:31] <Jartza> myself I find that nicer than most of the config-files or source-files with all the commas, parenthesis, brackets or other similar stuff
[15:31:37] <Jartza> and strict formatting
[15:32:46] <Jartza> but I wanted another opinion :)
[15:40:00] <gorroth> does no one know?
[15:40:19] <gorroth> z address gets set to 0x0000, and then i do an ijmp, but the device resets and goes back to bootloader
[15:41:03] <gorroth> i looked at my "blinky" objdump disassembly that i put at address 0x0000 on the flash, and i notice that main actually starts at 0x80, which i also tried to jump to, but with no luck
[15:41:12] <gorroth> __vectors are at 0x0000 of the blinky app
[15:41:52] <gorroth> and looking at it further, the reset vector should jump to __ctors_end, which will jump into main
[15:42:02] <gorroth> so jumping to 0x0000 from my bootloader should be just fine
[18:46:03] <corrideat> Hi. I'm trying to use the GNU stack to handle interrupts in an XMega 128A1U (in assembly), but I can't seem to get them to work (same code works on Atmel Studio)
[18:47:05] <corrideat> I'm guessing it has to do with that the interrupt table gets reordered when I compile, but I can't seem to figure out how to fix it.
[18:47:47] <corrideat> What do you suggest I attempt to get it working?
[18:50:40] <Tom_itx> are you using the asm include file from studio?
[18:55:18] <corrideat> Tom_itx, yes (in Studio). In GCC I'm using avr.h
[18:55:32] <Tom_itx> in asm?
[18:55:46] <Tom_itx> i mean the atxmega128a1udef.inc file
[18:55:55] <Tom_itx> defines the registers and interrupt vectors etc
[18:56:13] <corrideat> Actually, I just did avr-objdump on the ELF, and all my vectors (but the first one) are: "0c 94 0a 01 jmp 0x214 ; 0x214 <__bad_interrupt>"
[18:56:17] <Tom_itx> at least it should
[18:56:42] <Tom_itx> they jmp because they're not being used
[18:56:47] <Tom_itx> i think
[18:57:07] <Tom_itx> i do about || that much asm
[18:57:50] <corrideat> Tom_itx, right, it thinks they're not being used, but I've actually set some .ORG's that should be in the interrupt vector
[18:57:51] <Tom_itx> the PMIC is defined in the inc file
[18:58:36] <Tom_itx> i don't have a newer studio installed or i'd look at the inc for that part
[18:58:54] <Tom_itx> i've got a atmega128a1def.inc here but that's it
[18:59:40] <corrideat> Tom_itx, my registers are set up correctly. The issue is the interrupt table itself.
[18:59:46] <Tom_itx> you might find that file and include it
[18:59:48] <Tom_itx> hmm
[18:59:50] <Tom_itx> i dunno then
[18:59:59] <corrideat> I guess my question is now: how to tell GCC assembler that my .ORG 0x000-0x100 is supposed to be the vector table
[19:00:18] <corrideat> Thanks though
[19:00:26] <Tom_itx> i don't know but i do know i had to do that with the moto 68332
[19:02:54] <corrideat> Looking at
http://www.nongnu.org/avr-libc/user-manual/group__avr__interrupts.html, it may seem like I need to use a macro, ISR
[19:05:53] <Tom_L> for(j=2;j<256;j++) *(long*)(vbraddr+j*4) = *(long*)(j*4);
[19:05:56] <Tom_L> move %d0,-(%a7); /* save regs */
[19:05:57] <Tom_L> move #0x400,%d0; /* load new vector */
[19:05:57] <Tom_L> movec %d0,%vbr; /* store in vector base regs */
[19:05:57] <Tom_L> move (%a7)+,%d0"); /* restore regs */
[19:06:12] <Tom_L> *(long*)(vbraddr+64 * 4) = (long)tpu_int; /* 1st TPU interrupt handler */
[19:06:13] <Tom_L> *(long*)(vbraddr+80 * 4) = (long)hz100_int; /* PIT interrupt handler */
[19:06:13] <Tom_L> *(long*)(vbraddr+SCIVEC * 4) = (long)sci_int; /* SCI interrupt handler SCIVEC = 0x56 */
[19:06:28] <Tom_itx> that's how we had to do it for 68332
[19:06:32] <Tom_itx> even in c
[19:10:11] <corrideat> Thanks!
[19:10:28] <Tom_itx> that's not gonna help you much
[19:10:33] <Tom_itx> that was not an avr part
[19:10:40] <corrideat> I actually just discovered how it's done. Much easier than Atmel Sudio in fact :)
[19:11:30] <corrideat> .global RELEVANT_vect
[19:11:30] <corrideat> RELEVANT_vect:
[19:11:30] <corrideat> [assembly starts here]
[20:49:13] <rue_shop3> has anyone had problems with port B on the mega328?
[20:51:24] <Tom_itx> what sort of problems?
[20:51:28] <Tom_itx> is spi enabled?
[20:52:23] <Tom_itx> PB2..5 is spi
[20:53:22] <Tom_itx> PB6..7 are xtal pins
[21:12:30] <mzbotr> So I've got a crazy idea to use VGA from qemu running GNU invaders, create a bitmap, and drop it to an arduino on a serial line running vga output to a TV.
[21:12:43] <mzbotr> Do I sound crazy, or is this a good idea?
[21:17:19] <apo_> mzbotr: VGA on AVRs is... not easy
[21:21:14] <FL4SHK> apo_: obtain FPGA, use as video card
[21:31:04] <rue_shop3> I'm using pb0 and pb1, something really odd is going on where I cant read it properly
[21:35:37] <mzbotr> Qemu and python should be enough to capture and prepare the datagram from a raw socket to VM. As long as I'm using google code to keep the bitmap moving, should be fine, but then there are questions like "how big is too big for NTSC?" And I'm trying nothing special, only vgabios 320x200... Possible, someone has done this already. It doesn't look pretty, but you could use the arduino java mess to do this and I'
[21:35:43] <mzbotr> m pretty impressed.
[21:35:45] <mzbotr> https://www.hackster.io/janost/avr-videoblaster-8026fd
[21:35:48] <mzbotr> Pretty good read
[22:07:03] <rue_house> yup, good someone did it,
[22:07:13] <rue_house> considering what the old video games used to do
[22:07:14] <gorroth> so, i think i found out why i couldn't get my bootloader to jump to the application code without it crashing and rebooting the avr
[22:07:17] <gorroth> lock bits
[22:07:35] <gorroth> i changed the lock bits, and now i can jump to the application section, but ic an't rewrite it. so i have to figure out what i misunderstood about those and fix it
[22:33:35] <gorroth> it's so weird. on my atmega168, if i set lock bits to 0x3f, the bootloader can program the flash but can't jump to the code. if i then set the lock bits to 0x00, i can jump to the code on the flash, from the bootloader, but it can't program the flash
[22:34:04] <gorroth> of course, if i then want to reset the lock bits back to 0x3f, i have to erase the flash with ISP
[22:34:14] <gorroth> anyone know what's going on here?
[23:48:09] <gorroth> okay, i finally figured it out with a lot of thought
[23:48:19] <gorroth> i started thinking that the RWW wasn't enabled as it should have been
[23:48:34] <gorroth> so i added another boot_rww_enable() call just before jumping to the app