Back
[06:21:54] <cart_man> RikusW: Hi
[06:34:58] <RikusW> hi cart_man
[09:35:41] <abcminiuser> soul-d, patching it now
[09:57:24] <bss36504> abcminiuser: Can I make the MASS_STORAGE_IO_EPSIZE larger than 64?
[09:58:54] <abcminiuser> No, that's the max according to USB spec for those devices
[09:59:04] <bss36504> Thought so, just wanted to check
[09:59:07] <abcminiuser> Bulk endpoints for Full Speed max out at 64
[09:59:21] <bss36504> I skimmed chapter 9 this morning
[10:01:03] <bss36504> Documentation. Yuck.
[10:02:33] <tzanger> the documentation I end up reading tends to indicate that the authors shared your opinion.
[10:03:18] <bss36504> haha yup. We all hate writing it, and we all hate it even more when it's not there.
[10:07:04] <soul-d> currently cracking brain on resitive touchscreen with external adc :(
[10:09:07] <soul-d> probably wired wrong makes little sense so far and if it does seem to not the expected voltages like half vcc max
[11:20:53] <bss36504> soul-d: What seems to be the problem?
[11:24:19] <soul-d> no clue realy but my geus is that the avr doc and avr adc are dualing as gnd when other measurement is taken
[11:25:42] <bss36504> What chip?
[11:25:45] <soul-d> currently i have hooked up the 2 ports and the 2 - to an external (mcp3204) spi adc
[11:25:49] <soul-d> atmega 32u2
[11:26:57] <soul-d> maybe should try just 1 measure ment like horizontal or vertical and figure out how to get the proper ( 0 bottom ) 5v for top measurements before trying both
[11:29:06] <bss36504> The atmega32u2 doesn't seem to have an ADC.
[11:29:41] <bss36504> So you are trying to connect the X and Y of the touch screen to the mcp3204 and then use SPI to connect to the 32u2
[11:30:07] <bss36504> what seems to be the issue here? Are you not capturing data? Not the right data? Do you have a debugger?
[11:30:31] <soul-d> ive even tryied hooing up 2 more pins to the adc to act as hi-z and i think i
[11:30:37] <soul-d> well not correct inded
[11:30:52] <soul-d> max half vcc somewhere and doesnt seem consistent
[11:31:43] <bss36504> what happens if you try applying straight DC to one of the ADC pins to verify your code? What (if any) sort of output do you have from your MCU?
[11:32:53] <soul-d> it works got a temp sensor on channel 1
[11:34:04] <bss36504> so you are just unable to read the touch screen. Is it possible that you aren't sampling fast enough? (keep in mind the MCP3204 has a max sample rate of 100ksps)
[11:36:08] <soul-d> maybe sampleing verry slow just once 0.8 sec :P relying on serial time out to fetsh data
[11:37:20] <bss36504> That seems way slow. Why not just use a real time interrupt to poll at say 50ksps (account for SPI transaction) then use other interrupts to handle the rest of your code.
[11:41:24] <soul-d> could try that currently using serial as activatior like to select channel take a single conversion but id expected to measure at least somewhere near correct value if i holded position
[11:43:36] <bss36504> does the conversion jump all over the place or is it plain not correct? can you connect a scope to the X and Y leads to get an approximation of the voltage to convert?
[11:45:49] <soul-d> only have a multimeter but i broke it again ti seems now only measure 5v :(
[11:46:30] <soul-d> ill take some coffee leave it alone for a bit
[11:47:10] <soul-d> well not all over the place just not correct
[11:47:42] <soul-d> like 0.3-2.2 v instead of 0.3-4.8~
[11:49:26] <bss36504> is there a part number for this touchscreen?
[11:51:40] <soul-d> and onlt by pressing hard but that before i left currently broke the code
[11:51:57] <soul-d> ]no got a simple one sheet datasheet with the non custom howto
[11:55:44] <bss36504> Well thats not very helpful...is it possible it's not designed to work at 5 volts?
[11:56:01] <soul-d> it is
[11:56:18] <bss36504> ok....
[11:56:37] <soul-d> http://pastebin.com/DWCkf3CW
[11:57:14] <bss36504> I'm assuming that is the data from the serial port?
[11:57:22] <soul-d> yes
[11:59:57] <soul-d> http://i.imgur.com/ZT75qWH.jpg
[12:01:21] <soul-d> cureently have 1 and to to port outputs and 3/4 to adc
[12:02:23] <soul-d> but thats where i assume the avr doc abuses the adc ports and gnd current sink wich when measuring th the external adc doesnt do
[12:05:58] <bss36504> But this avr doesn't have an ADC. It should only be connected via SPI. When you apply +5V to pin 2, and place your finger in the middle, you measure ~2.5V on pin 4?
[12:08:54] <soul-d> im suplying the +5 by 2 port pinsturning of measuring the other , but let me try a more simpler setup like that afther coffee also found hiddin sticker never noticed before
[12:08:56] <soul-d> http://imgur.com/38MzlDE
[12:09:04] <soul-d> maybe more stuff on the net
[12:10:43] <bss36504> Yes, I need lunch. I
[12:10:48] <bss36504> I will be on later.
[16:43:50] <Roklobsta> try ###arm
[16:54:45] <bsdfox\> what is ### for?
[16:56:36] <Casper> for typos
[16:58:17] <Roklobsta> special channel for one person only
[17:27:11] <nn7> I have some AVR code that will often get stuck in a reboot loop. Occasionally it does not get stuck in the reboot loop, and will behave fine until the next time it is power cycled. Once it starts the reboot loop it never escapes. The reboot cycle does not always happen in the same part of the code.
[17:27:49] <nn7> Right now I have the device on and it is in a very short reboot loop. I have changed the code a few times and reprogrammed it, the reboot loop continues.
[17:29:42] <nn7> I have reduced the code to this and programmed it:
http://pastebin.com/bXU1yb9k
[17:31:12] <nn7> I see the initial high and low and high of PB4, then after 18 ms that pin starts to bleed off (tri-state), then there's a 74ms delay and the procedure repeats.
[17:32:29] <nn7> This same delay is in the production code. Sometimes it reboots in the middle of this delay, sometimes it reboots later (always within a few seconds), sometimes it doesn't reboot at all.
[17:32:52] <nn7> but the reboot frequency only changes when I power cycle the device, not when I reprogram the microcontroller.
[17:34:13] <nn7> I am at a loss, I've never experienced anything like this before.
[17:37:47] <nn7> The chip is an ATMEGA324P with an external clock.
[17:38:24] <nn7> There's an external 20mhz crystal and a startup of 16kck and 65ms
[17:43:06] <nn7> If I take out everything but the DDRB, PORTB |= and the while(1) statement it still goes into a reboot loop.
[17:44:56] <nn7> With this code:
http://pastebin.com/XHA23QH6 the chip still reboots after 18ms.
[17:46:35] <RikusW> watchdog timer ?
[17:47:01] <RikusW> or brownout ?
[17:49:00] <nn7> BOD is disabled.
[17:49:23] <nn7> WDTON is not checked.
[17:50:26] <nn7> If I power cycle this thing the reset time will change, or it may stop resetting.
[17:50:49] <RikusW> uninitialized variables ?
[17:51:07] <nn7> Take a look at the code. There are no variables.
[17:51:27] <nn7> http://pastebin.com/XHA23QH6
[17:51:41] <nn7> The program is 196 bytes.
[17:54:32] <RikusW> how do you know it resets ?
[17:55:04] <ColdKeyboard> Is there some IC that can drive 10 LED bar graph with SPI or something like that?
[17:55:06] <nn7> I'm watching the output of PB4 on an oscilloscope
[17:56:08] <ColdKeyboard> OR even better to control 2x 10 led bar graph displays?
[17:56:19] <RikusW> WDT
[17:56:28] <RikusW> or brownout
[17:56:32] <RikusW> BOD fuse
[17:56:37] <N1njaneer> nn7: Check to make sure you don't have a short on the IO pin that might be drawing excess current through the device - i.e. something shoted to ground or VCC as well
[17:56:46] <N1njaneer> Or any other pin on the device.
[17:57:08] <N1njaneer> Beyond that I'd check the BOD and WDT settings as have been suggested.
[17:57:20] <nn7> RikusW, both WDTON and BODLEVEL are disabled
[17:57:23] <N1njaneer> ColdKeyboard: TI had a TON of chips that will do exactly what you want
[17:57:51] <N1njaneer> Constant-current LED drivers built in, too. And a lot that will just do on/off rather than PWM which may be simpler for your application.
[17:57:56] <N1njaneer> +has
[17:58:05] <N1njaneer> Look in the TLC series of parts
[17:58:40] <RikusW> whats connected to the reset pin ?
[17:58:48] <RikusW> at least a 10k pullup ?
[17:59:13] <N1njaneer> Also is the chip adequatly decoupled with 0.1uf's on all power pins? Clean supply?
[17:59:44] <nn7> there's a 20k resistor from RESET to VCC.
[18:00:31] <N1njaneer> nn7: Also, how do you know this is resetting? Did you answer that? I might have missed it.
[18:00:42] <nn7> The device in question is a PCB with an FT323RL and the ATMEGA324p. Both chips have both 0.1uf and 15uf decoupling caps.
[18:01:11] <nn7> It's a generic board I designed for interfacing to various devices. I have probably a dozen of them in use and none of them exhibit this behavior.
[18:01:30] <nn7> This one in particular connects to an RS485 driver chip (which is currently connected to nothing)
[18:02:02] <nn7> N1njaneer, I'm watching the output on an O-scope. The output pin remains high for 18ms and then starts to bleed (probably tri-state). About 74ms after that the pin goes high again.
[18:02:06] <N1njaneer> Have you tried putting your finger on the chip to see if you are getting any excess heat generation?
[18:02:28] <N1njaneer> Does the IO go to anything, or is it just a spare unconnected one?
[18:02:36] <nn7> I just tried that and I feel no warmth from the chips
[18:02:46] <nn7> it's a spare unconnected IO pin that I'm probing
[18:03:06] <N1njaneer> That's a strange one. Definately compiling for the 324P target?
[18:03:23] <ColdKeyboard> N1njaneer: I took a look at TI chips and I found LM396 but it operates based on input voltage, I need something like SPI or I2C or anything else digital... Any suggestions?
[18:03:24] <N1njaneer> No BOOTRST or anything set I assume
[18:03:32] <nn7> The power source is a USB port. I have previously probed the VCC line and verified that it is smooth. I have repeated this behavior on multiple machines
[18:03:43] <N1njaneer> ColdKeyboard: Yes, search "TLC5" on DigiKey
[18:04:15] <N1njaneer> There are tons of 8/16-bit shift registers that will run 8 or 16 constant current outputs made to be attached straight to LEDs. They are normally used in the signage industry.
[18:04:35] <nn7> Just verified the build target is the atmega324p
[18:05:01] <N1njaneer> An example is the TLC5916N --
http://www.ti.com/lit/ds/symlink/tlc5916.pdf
[18:05:08] <nn7> " -mmcu=atmega324p "
[18:05:18] <N1njaneer> There's a bunch of others in that family with more outputs, etc
[18:05:32] <nn7> if I power cycle this, the reset time will change, and sometimes it doesn't enter a reboot cycle at all
[18:05:34] <N1njaneer> Basically it's a shift register wired straigth to 8 constant current drains.
[18:07:12] <N1njaneer> nn7: I'd suggest trying to monitor a different pin as well and see if you get the same kind of behavior. Or move the output to a different pin as well. Basically to see if you can produce the same behavior. Or put a toggle of your IO pin in the while look to see if you can see any of a square wave coming out, etc.
[18:07:28] <N1njaneer> Basically need some more tests to gather further info.
[18:10:06] <nn7> ok! I changed the code to this:
http://pastebin.com/NNtcUJky
[18:10:59] <nn7> I see PB2 toggle on and off quickly while PB4 is high.
[18:11:30] <nn7> The reset time is not precisely the same because sometimes PB2 is off and sometimes PB2 bleeds tri-state like PB4 does
[18:11:46] <nn7> but it's very close to the same time
[18:11:50] <nn7> within a few clocks
[18:12:17] <nn7> I can't tell for certain because this scope does not have enough memory to scroll that far past trigger.
[18:29:33] <nn7> Any more suggestions?
[18:29:36] <nn7> Could the chip just be bad?
[18:29:55] <nn7> The program that usually runs on it is pretty complex, and if the chip runs for 2 seconds it runs for hours.
[18:30:09] <nn7> I've never had it last more than a few seconds and then lock up / reboot
[18:47:32] <nn7> I power cycled the device, no reboot
[18:54:54] <nn7> Another power cycle and I'll have a different reset time.
[19:00:10] <N1njaneer> nn7: Back, sorry
[19:00:17] <N1njaneer> What is your clocking arrangement?
[19:00:29] <N1njaneer> Have you tried setting to use internal 1Mhz oscillator?
[19:00:57] <N1njaneer> I've seen instances where errors in the clock settings, crystal, biasing caps, etc can cause undefined behavior
[19:01:03] <nn7> External 20mhz. I will try 1mhz internal.
[19:01:20] <N1njaneer> You are powering from +5V?
[19:02:05] <nn7> yes
[19:05:27] <nn7> 1mhz internal, maybe 20 power cycles, no reboot traps
[19:06:00] <N1njaneer> I'd check your oscillator characteristics and settings, then.
[19:09:09] <nn7> I set the oscillator settings back to what they were and have been unable to trigger the reboot trap
[19:09:27] <nn7> I've had this problem before when trying to debug this problem. When it starts acting right I can't make it act wrong.
[19:09:44] <nn7> But every time I take it some where I'll sometimes have to go through a dozen power cycles before it acts right.
[19:10:25] <N1njaneer> I would double-check the oscillator and settings for it. At least it sounds like this has helped isolate it.
[19:10:40] <N1njaneer> Do you have CLKOPT set?
[19:10:46] <N1njaneer> Try setting it if not
[19:10:53] <nn7> yes. Let me see if I can access that pin
[19:11:26] <N1njaneer> I have seen some abnormalities in some silicon revs that will require CLKOPT to be set to get reliable behavior while other revs work fine without it.
[19:13:49] <nn7> yup, it's available
[19:21:46] <nn7> Ug, I have no great way to probe 20 mhz. Let me solder on a tail
[19:25:19] <nn7> A little rounded but otherwise the clock looks good.
[19:27:17] <nn7> I can scroll out 2.5us past my trigger point and I don't see any jitter
[19:27:22] <nn7> of course it's not resetting now
[19:40:10] <N1njaneer> Very strange one. Hopefully this has helped to isolate it a bit further, though :)
[23:00:05] <MarkX> i did something kinda dumb
[23:00:25] <MarkX> and i'm wondering if i effed something up
[23:02:51] <MarkX> i had a pot connected to vcc and gnd, wiper going to pin d3 on an atmega32u2
[23:03:19] <MarkX> now when i try and get the current reading from that register, it keeps switching from F8 to F0 and back
[23:03:24] <MarkX> am i boned?
[23:07:00] <Casper> first, what is the AREF that you selected?
[23:07:08] <Casper> second, is the ADMUX set to the right value?
[23:07:30] <Casper> third, often the ADC is shared with jtag, is jtag disabled?
[23:08:48] <MarkX> there is no ADC
[23:08:58] <MarkX> i do not know what AREF and ADMUX are
[23:12:00] <MarkX> ah AREF and ADMUX are related to ADC
[23:12:28] <MarkX> yea this chip has no ADC, i thought it did so i set up the pot, then learned last night that it didnt..... but i didnt take the pot off before turning it on today....
[23:21:54] <Casper> ok
[23:25:55] <MarkX> yea looks like something wonky is going on now
[23:25:57] <MarkX> :(
[23:34:15] <Casper> the pot may also act as an antenna
[23:34:44] <Casper> a digital pin ain't supposed to be floating, or with an "unknown" voltage
[23:34:51] <Casper> it's supposed to be near 0 or near VCC
[23:34:54] <Casper> not "in between"
[23:42:16] <MarkX> well i removed the pot
[23:42:22] <MarkX> and its still behaving erattically
