Back
[13:36:04] <Samir436> Hi
[13:41:02] <Fast> Hello
[13:43:12] <Fast> may I talk to someone?
[13:43:22] <learath> nope. Talking is not allowed in this channel.
[13:43:23] <Fast> regarding avr issue?
[13:43:50] <Fast> so, it's for silent starring?
[13:44:13] <learath> Yep. We communicate through a complex protocol of blinks.
[13:45:19] <Fast> talking about complexity
[13:45:52] <Fast> does deing engineer means being odd
[13:46:05] <Fast> -_-
[13:46:56] <Fast> yaw I need someone
[13:47:13] <Fast> in serious help
[13:49:49] <Fast> just someone tell me what are you doing here?
[13:49:56] <Fast> chatting in private?
[13:51:01] <Fast> ENCOURAGE PEOPLE OR WE WILL SQUASH YOU.
[13:51:04] <Fast> !!
[13:52:07] <learath> TBH this channel is pretty dead on the weekends. What's the question
[13:52:35] <Fast> thanks GOD
[13:52:56] <Fast> but why they are online?
[13:53:13] <Fast> anyway
[13:53:28] <Fast> I'm working with atmega32
[13:55:06] <Fast> and when I program PORTC to blink with delay it works in the Proteus but not in the real Micro
[13:55:56] <Fast> actually PINC2 through PINC4 not blinking
[13:56:07] <Fast> I code using codevision
[13:56:23] <BusError_> very popular choice
[13:56:36] <Fast> and upload the Hex using AVRDUDE
[13:56:58] <learath> What if you use a different port?
[14:00:01] <Fast> wait will try it now
[14:03:31] <Fast> PORTA works well
[14:07:49] <learath> any chance portc is blown?
[14:09:15] <Fast> I have two Micros
[14:09:30] <Fast> and they behaving the same
[14:09:36] <learath> and porta works on both, while portc does not?
[14:09:45] <learath> that's weird. and means there's something weird with the micro, and I have no idea what
[14:09:49] <learath> read the data sheet again?
[14:10:35] <Fast> I read it multiple times
[14:10:51] <Fast> although I started to doubt
[14:10:56] <Fast> here it is
[14:11:22] <Fast> Atmega32A PU
[14:11:44] <Fast> the datasheet is Atmega23A
[14:12:54] <Fast> I guess it is the right datasheet
[14:13:03] <learath> is there something else on portc?
[14:13:09] <Fast> but look at the behaviour again
[14:13:29] <Fast> on
[14:13:31] <Fast> no
[14:13:38] <learath> you said portc 2-4 don't work right?
[14:13:52] <Fast> I created new code only to test the behaviour
[14:14:08] <Fast> PINC0 and PINC1 works well
[14:14:24] <learath> Yeah, and you say porta works, and portc0,1, is there a 5-8?
[14:15:15] <Fast> PINC2 and PINC3 output weak Pulse
[14:15:36] <Fast> PINC4 doesn't work at all
[14:16:02] <Fast> PINC5 gives weak pulse
[14:16:10] <learath> And you've set them all correctly as outputs?
[14:16:12] <Fast> 6 and 7 works well
[14:16:19] <learath> can you pastebin your code?
[14:16:21] <Fast> 0xFF
[14:16:24] <Fast> for DDRC
[14:16:31] <Fast> ok
[14:16:35] <learath> and what exact board are you using
[14:17:10] <Fast> I'm using a bread board
[14:17:22] <Fast> and arduino as avrISP
[14:17:55] <learath> and you said a Atmega32a PU?
[14:18:02] <Fast> yes
[14:18:31] <learath> datasheet HO!
[14:18:32] <Fast> the Atmega32a PU is the micro I use in my project
[14:18:47] <Fast> Atmega32A
[14:18:50] <Fast> the datasheet
[14:18:57] <Fast> http://pastebin.com/E1YHrk4X
[14:18:57] <learath> I just don't have it handy, grabbing it now.
[14:19:02] <learath> I tend to use the atmega 328p
[14:19:10] <Fast> okk
[14:20:40] <learath> dip?
[14:21:16] <learath> interesting. those are the JTAG pins
[14:21:35] <Fast> yes
[14:21:36] <Fast> then?
[14:21:37] <learath> (pc2 is TCK, PC3 is TMS, PC4 is TDO and PC5 is TDI) do you have JTAG enabled?
[14:22:46] <Fast> I think so
[14:23:07] <learath> yeah. PC2-5 won't work with JTAG enabled.
[14:23:10] <learath> it's either or
[14:24:27] <Fast> yes
[14:24:31] <learath> The reason you are seeing weak pulse is you are actually seeing JTAG data
[14:24:32] <Fast> it's enabled
[14:24:32] <learath> or clock
[14:25:24] <Fast> http://www.engbedded.com/fusecalc
[14:25:35] <Fast> this is the configuration I'm using
[14:25:46] <learath> That didn't work. but, JTAG or portc, pick one
[14:26:10] <learath> also, be careful disabling programming interfaces. it's easy to get into an annoying state
[14:27:58] <Fast> if I disable the JTAG will it effect the ISP programming option?
[14:28:19] <learath> it shouldn't. But if you forget later and decide you need the ISP pins...
[14:30:07] <Fast> no I won't
[14:30:51] <Fast> as I don't have standalone programmer
[14:31:03] <Fast> but interesting
[14:31:11] <learath> I'm by no means saying "don't do it" I'm just saying be careful.
[14:31:45] <Fast> yes, I got you
[14:32:36] <Fast> then thank you
[14:32:54] <Fast> I go to complete my troubleshooting
[14:33:07] <learath> lemme know if it works
[14:33:47] <Fast> if you send me your email in private I will send you the whole project I'm working on
[14:38:56] <Fast> it worked
[14:39:23] <Fast> exactly after disabling the JTAG
[14:39:59] <Fast> thanks learath
[14:40:53] <Fast> bye
[15:35:36] <rue_house> ** remember to disable the jtag that is by default on in order for your ports to work properly **
[15:42:30] <learath> rue_house: yep :)
[17:04:37] <Fleck> so, anyone knows why vector function is not called in flash when bootsz0:1 is programmed and bootrst too, and there is no bootloader!?
[17:04:44] <Fleck> atmega 2560
[17:09:14] <Tom_itx> still fighting that ehh?
[17:09:21] <Fleck> yeah :/
[17:10:08] <Fleck> throw some ideas Tom_itx :)
[17:11:41] <antto> Fleck the fuses are set as "use is bootloader", and the problem is that interrupt isn't working while running the firmware?
[17:11:54] <antto> * "use bootloader"
[17:12:19] <Fleck> yeah, and there is no bootloaders, so bunch of noops
[17:13:11] <antto> have you set the interrupt vector to be in the boot section, and perhaps forgot to move it back to the FW section?
[17:14:02] <Fleck> MCUCR? tried that, not helping! :D
[17:14:36] <Fleck> why are you asking me this again antto? :D you know all that problem
[17:14:54] <Tom_itx> app 109 is bootloader
[17:15:41] <antto> just asking to make sure i understand the issue
[17:15:55] <Fleck> Tom_itx: I have tried that, did not work! :/
[17:16:12] <antto> in case you were trying some stuff (i wasn't paying much attention last few days)
[17:16:30] <Fleck> feels like antto forgot me :p
[17:16:49] <antto> i haven't
[17:17:03] <Fleck> Tom_itx: can you tell me - what's the new vector value should be?
[17:17:05] <antto> i am not totally familiar with this MCUCR thing tbh
[17:18:35] <Tom_itx> i could but then i'd have to shoot you
[17:18:47] <Fleck> ;p
[17:18:48] <Tom_itx> honestly, i haven't done alot with bootloaders
[17:19:49] <Tom_itx> maybe when the bootloader is done, it resets them back to their original location
[17:19:59] <Tom_itx> or should*
[17:24:10] <Fleck> _VECTOR(17) is the one I'am trying to use, works great when there is bootrst unset, so, antto had _VECTOR(21) or whatever for timer0 working OK, but not for timer3, and me for timer1 :/ Maybe I should try timer0 :D
[17:24:31] <Tom_itx> shouldn't matter
[17:27:35] <Fleck> ok, I'll check that Tom_itx! :)
[17:30:35] <Tom_itx> what exactly are you trying to do?
[17:30:45] <Tom_itx> and why
[17:31:10] <antto> in my bootloader (i think i've said that but still) i set MCUCR once on init, and again on "exit" (before the jump to FW section)
[17:31:31] <antto> the FW itself doesn't touch MCUCR at all
[17:35:01] <Fleck> trying to understand and learn Tom_itx! :)
[17:49:41] <Tom_itx> how's that goin for ya?
[17:55:03] <Fleck> Tom_itx: ... :) hard! :P
[17:55:09] <Fleck> I just don't get it!
[17:55:57] <antto> so, timer priority was what we discovered last time
[17:56:20] <Fleck> and antto, timer 0 compa is not working here either!
[17:56:32] <antto> tho, i never actually tried it as i already had given up and moved the code back to run on the 1kHz timer
[17:56:41] <antto> hm
[17:57:13] <Fleck> as Tom_itx predicted, and, the same as timer1, when bootrst fuse is unset - working ok!