Closed darudude closed 10 years ago
hi, please use an UNO and reopen if that doesn't fix the issue.
I don't have a UNO at the moment. Is there anything you guys can do to help me out?
Make sure you're using Arduino 1.0.5/1.0.6 and not the newest 1.5.7 or 1.5.8 beta to run the driverpatch sketches. Right now they don't compile with 1.5.7, but if you do fix the compiler error and run them they'll have similar lockup issues. Haven't had a chance to debug much further, but the fix is to drop back to 1.0.5 and rerun the firmware upload.
Also make sure you've got a good 1 amp or more capacity power supply for your chip. It's really common for powering a chip over a USB port (or with a less than 1 amp supply) to have lockups at initialization like you see too.
@darudude if you're interested in using the ATmega1284 with the CC3000 you might want to take a look at WildFire (wildfire.wickeddevice.com).
Thanks for getting back to my @tdicola!
I was using 1.0.6 and reverted back to 1.0.5, however, I still have the same issue. I also ensured that my PS is able to supply more than 1A to the chip.
Any other thoughts? It throws me off that it works for all sketches where I use serial.begin() without any parameters.
Try measuring the voltage to the CC3000 VIN pin with a multimeter when it's in a bad state. Just to rule out a power issue, check that it's around 5V as expected.
I can rule out the power issue. I hooked up the CC3000 directly to a power supply (the current draw does go near 1A).
I have the same issue - I can run Buildtest and everything works; the driverpatch sketch breaks when it hits the CC3000.begin(2) command.
Another thing to check is the clock speed your 1284p setup is running at, is it 16mhz or something else? The CC3000 is pretty sensitive to the speed of the SPI bus and by default the library uses CPU clock / 2 (8mhz). If you're running at other CPU clock speeds this might not be set to the same value and could give some weird failures like this.
The 1284P is running at 16Mhz (via a crystal).
Hi, I have an Uno and a Mega. The firmware script works fine on the Uno and hangs as described in this thread on the Mega. It is beyond me why it hangs on the Mega. Could be same problem on Mega and @darudude board.
Hrm unfortunately I don't have any more suggestions for the 1284P. You'll probably want to try debugging a little further to see if the CC3k is responding and perhaps not being picked up by the AVR. When the AVR wants to talk to the CC3000 it will pull the VBEN pin low and then the CC3000 should pull the IRQ pin low to confirm it's ready to receive data. When the sketch isn't responding, you might check to see if those pins are pulled low or if the CC3000 IRQ is still high and the CC3k isn't responding for some reason. If you have one a digital scope or logic analyzer is really helpful to track down weird issues like this.
warezak, one thing to check with the mega is the power source. Make sure you're using an external 7-12 volt 1+ amp power supply plugged into the barrel jack and not powered through the USB port to a computer or laptop. USB ports are notoriously bad about giving enough power to run an Arduino + CC3000--I've seen a few cases where only the firmware update sketches pull enough power to be a problem with power related lockups.
@tdicola I removed my oled display from the mega and that fixed the problem. the display may have been drawing enough power to mess it up. working now on mega. thanks
after further review, my issue was due to CS pin mapped incorrectly. overlooked it.
@tdicola - still debugging away. Don't have a scope handy, so will head over to the university sometime this week to take a look at the transmission lines. Will get back to you
@tdicola - managed to make it work. Had to use an Arduino UNO instead of the Atmega1284P. It just seems strange that it would only work with the UNO, considering the sketch was exactly the same (with the exception of the pinouts), and I can get all the other sketches working with the Atmega1284P
@darudude almost certainly an issue with your 3rd party hardware files / arduino core. If you're, for example, if you're using the Mighty1284P core, it's ancient and has issues with memory allocation among other things.
@WickedDevice - I can see that being it. Are there any other cores you recommend?
@darudude with WildFire I use the standard arduino core with a tailored pins_arduino.h for my pinout.
@vicatcu - That is very cool. I had seen an instructable getting an alternate version of the core on to any AVR8 device (http://www.instructables.com/id/Arduino-on-all-sorts-of-Atmels/?ALLSTEPS) when I had decided on the 1284P, but the info was outdated and inadequate, and I couldn't find anything around configuring newer versions of the core on the chip. If you have any materials you used, I wouldn't mind looking through it to get myself up to speed on the process
@darudude check out https://github.com/WickedDevice/WildFire-Arduino-Core is the concrete example and https://github.com/arduino/Arduino/wiki/Arduino-IDE-1.5---3rd-party-Hardware-specification is the spec on how it's done.
@vicatcu - Perfect! This is what I wanted to see :)
I'm trying to upgrade my CC3000 firmware, but I'm running into the issue described in the title.
I'm able to start the process through the serial monitor, and it displays the RX/TX buffers and RAM on the CC3000, but crashes during initialization.
What's throwing me off is that when I run buildtest or one of my own sketches, I can get past the initialization process without any issues.
Could this have something to do with the "if (!cc3000.begin(2))" command on the driverpatch sketches? buildtest and the other sketches that work use cc3000.begin()
In all cases I'm using an Atmega1284p with the ManiacBug bootloader.
Any help would be appreciated!