Program a pic32mx250f128b with pic32prog on an arduino uno - arduino

I'm currently trying to burn the pinguino bootloader in a pic32mx250f128b which is 5V tolerant with an arduino uno. I'd want to try pic32 chips, but I haven't a pickit3 now, I can only access to pickit2.
So to burn the bootloader I'm using an arduino uno, and use the bitbang sketch from pic32prog to try to burn it.
For the wiring I did this :
All VDD and the VUSB3V3BUS pins are wired to the 3V3 regulator of the arduino uno.
All VSS pins are connected to the ground of the arduino uno.
Arduino D2 (PGC) is directly connected to PGEC1
Arduino D3 (PGD) is directly connected to PGED1
Arduino D4 (MCLR) is directly connected to MCLR
But actually, when I launch pic32prog I always have this output :
Programmer for Microchip PIC32 microcontrollers, Version 2.0.218
Copyright: (C) 2011-2015 Serge Vakulenko
(ascii ICSP coded by Robert Rozee)
Adapter: ... OK1 OK2 - ascii ICSP v1E
No target found.
I tried also with the couples PGEC2/PGED2 and PGEC3/PGED3.
I haven't tried to use a crystal yet, but I think from what I read it's not needed for ICSP programming.
For now here is what I've done on my breadboard :
photo of the pic on the breadboard
I don't know what could cause this detection problem,
Thank you very much for your help :)
Edit : I tried several things and here is where I am :
I added the pull-up on MCLR, capacitors on VDD pins, and others recommended : Still the error No target found.
I saw that pic32prog add compatibility with pickit2 so I tried it : this time the pic is detected but I get this error : Unknown CPUID : ffffffff. I tried also with a new pic32mx250 on the pickit2 to be sure it wasn't the first which was damaged.
Finally to recheck my connections I found another version of the datasheet. In this one it seems that PGECx and PGEDx pins aren't 5V compatible... -> So I'll test with 3.3v compatible circuit this time

you need 3k3 pullups to the 3v3 supply rail on both PGC and PGD. these two outputs are 'open collector' (simulated) and the 3k3 resistors define the logic '1' voltage fed to the PGC and PGD pins of the target PIC32.
as mentioned by others, you also need a 10k pullup on MCLR. in addition, you need to ensure that all Vcc pins (13 and 28) are connected together, all ground pins (8, 19 and 27) are connected together, and that there is a 10uF low ESR ceramic capacitor from pin 20 to ground (a 22uF tantalum will do).
see the "ascii ICSP construction guide" article here:
http://www.thebackshed.com/docregister/Browse.asp
the article includes a schematic of what is required.
cheers,
rob :-)

the 10uF low ESR ceramic capacitor on pin 20 is crucial. pin 20 connects ONLY to this capacitor, nothing else. without it, the core of the PIC32 will not run and programming will be impossible.
the reason for this is that the core of the PIC32 runs at 1.8 volts, and the capacitor on pin 20 is part of the circuitry that generates this supply. in your photo it looks like pin 20 is not connected to anything.
cheers,
rob :-)

Related

Error in Arduino with Espressif ESP32-CAM [duplicate]

I've just recieved my very first esp32cam (AI THINKER) today and I was excited to test it, but I'm unable to upload any code to it. I'm always getting the following error:
Failed to connect to ESP32: Timed out waiting for packet header
So, the FTDI I'm using is the FT232r with the following wiring scheme
FTDI Wiring
How I reproduce this error:
Plug everything
Order IDE to upload the sketch
Wait for the "connecting" text
Press the RST button
Also:
Plug everything
Press the RST button
Order IDE to upload the sketch
I've already tried:
Switching to 3.3v (plugged on 3.3v pin)
Using external 5v power supply (plugged on 5v pin)
Using another computer
Swapping RX TX
Trying in different upload speeds
Holding RST button
Switching board between ESP32 Wrover Module and AI Thinker ESP32
I'm I doing something wrong or there's just something faulty?
I have delved for a solution in this regard for weeks and it seems I have a solution.
Findings-
FTDI module is probably faulty or not supported for each instance.
Aithinker Board is not compatible with esspressif (use ESP32Wrover, more details below )
I have an esp32cam from Esspressif, not Aithinker.
I was trying with FT232rl , No matter what Voltage/jumpers/USB cable I used, it didn't work. Always stuck with fatal timed out error.
After many futile attempts with FTDI breakout, I gave my Arduino UNO a try (please note my UNO has mega16u2 chip as USB serial chip (top right corner just beside the oscillator) and fortunately it worked.
I have read that CP2102 is also working.
**Here are the steps to follow-**
Arduino ESP32Cam connections
3.3 Arduino --------- 3v Esp32CAM
GND Arduino ------------ GND Esp32CAM
RESET Arduino to Ardunio GND
RX Arduino -------------- VOR Esp32CAM (this is not a mistake RX to rx & TX to tx)
TX Arduino -------------- VOT Esp32CAM
GPIO 0(zero)(written as IO0) Esp32CAM to GND Esp32CAM
I didn't have any need to press the reset button in any part of the operation before & during uploading.
I am assuming You have pre-installed the esp32 board manager.
Now select the correct COM port where your Uno (in this case) is
plugged in.
Select the correct board as mentioned
Tools>Board>ESP32 Arduino > select ESP32 Wrover Module
Some uploading setups are to be Done (Under Tools, these will only appear when the Wrover module is selected )
Upload speed -- 115200
Flash Frequency -- 40Mhz
Flash Mode -- QIO
Partition Scheme --- Huge App
Port ---- select the right com port for your breakout or UNO
JUST press upload and relax
After a while, you will be able to see this message
Leaving...
Hard resetting via RTS pin...
Disconnect the Esp32Cam GPIO 0 and GND
Power the ESP32Cam with 5/3v with external power supply (Arduino or other breakouts may not be able unless you are connected with a Powered USB Hub)
keep TX, RX, & GND of the 2 boards connected, don't disconnect Arduino Reset and GND.
Press Reset on ESPCAM and open Serial monitor and you will be able to see the IP address of the cam if it was configured with your wifi correctly.OR get any network scanner App on android or windows.
I hope it helped.
Pre-requisites for flashing:
ArduinoIDE 1.8.12
Core ESP32 1.04 (at time of writing)
Select board AI Thinker Cam
uplooad speed 921600
freq 240Mhz
flashfreq 80Mhz
mode QIO if not working try DIO
partition scheme default
Serial monitor is closed
NO hardware connected to the pins of the ESPcam
Make sure the USB cable is a data cable and NO loading cable only
check Windows device manager if programmer is shown and has max speed / 8n1 hardware
Connections
FTDI - ESP32
GND GND
5V 5V
TXD UOR
RXD UOT
If you use an AIThinker Cam clone you have to ground GIPO 0:
connect GPIO 0 with a dupont wire connected to GND
press reset
compile and upload (use AI THINKER CAM)
optional:
press reset
upload filesystem data (SPIFFS)
disconnect GPIO 0 and GND
press reset
code should execute
And yes you have to do it every upload, on my dev board I soldered a little switch with proper isolationSome more solutions from experience:
If there is still a problem use a 10K (or so) pull-down resistor between RX0 and GND (test on breadboard before soldering)
Pressing and holding (!) the boot-button while uploading on some "bad" boards
Happened with a "normal" ESP32 board to me - just to be sure - I got an ESP8266 in an ESP32 packaging. Configuring for the ESP8266 solved the issue of uploading.
In my case I forgot to remove the SD card. Other users recommended removing unnecessary connections to the pins-- and the SD card technically uses some of those :)
This was solved by using other jumpers. It seems one of the jumpers used in the wiring was faulty.
If you're having the same issue and tried everything in this post, try checking your cables!
Another solution here. Just to add, I tried everything on this QA, as well as many other things suggested online. e.g. tested by powering from 3.3V then 5V, various permutations of holding the reset button down and disconnecting IO00 from GND at the point of flashing. Changing various settings in Arduino IDE/
I was unable to flash a single one of the 5 ESP32-CAM boards I bought. Spent a good two hours on it. I even continuity tested every pin on the board to its ESP32 chip pad, and all the hookup wires were tested too. The board seemed fine.
Then I soldered a 100uF capacitor between 5V and GND, and used my USB-UART 5V power... tested and worked straight away. No need to pull out the IO00->GND connection and no need to press RST button on the board during flashing. (Of course, pull out IO00->GND after flashing complete.
So - it was a power problem.
I can only guess that the cheapo regulator they used on the copy of board that I got was not quite efficient enough, but basically that capacitor resolved the issue.
p.s. the ESP on board was marked "ESP32-S". I selected "AI Thinker ESP32-CAM" in Arduino IDE as suggested by most people online, and this worked.
There are 3 pins marked GND on the ESP32-CAM board. Buuuuut (!) the one marked GND/R just by the U0T is NOT connected to other grounds or anywhere else I could had find. Check with a multimeter and use a REAL GND. It just worked for me after days of puzzling.
If you try it with arduino it works but its needed to press reset button on esp32 before you upload your code
Basically I was facing the exact same problem fro quite some time. What worked for me was that as the chip was flashing, shifting the power wire from 5V to 3V3 pin. I do not know why but it workes. When esptool starts flashing at 2%, switching the cable just then, despite having 5V from supply into the 3V3 point made the flashing successful. I do realize this is probably a bad answer to your problem since it involves oversupplying voltage to the chip on the wrong point as it is flashing and could damage the chip. However, if anyone is tired of debugging and are at the point where you are considering throwing the chip away, might as well try my method. For other's who value their chip, don't try this method and if you still do, kniw it is at your own risk. But it worked for me after 3 days of just messing around with connections.

Esp32cam Failed to connect to ESP32: Timed out waiting for packet header

I've just recieved my very first esp32cam (AI THINKER) today and I was excited to test it, but I'm unable to upload any code to it. I'm always getting the following error:
Failed to connect to ESP32: Timed out waiting for packet header
So, the FTDI I'm using is the FT232r with the following wiring scheme
FTDI Wiring
How I reproduce this error:
Plug everything
Order IDE to upload the sketch
Wait for the "connecting" text
Press the RST button
Also:
Plug everything
Press the RST button
Order IDE to upload the sketch
I've already tried:
Switching to 3.3v (plugged on 3.3v pin)
Using external 5v power supply (plugged on 5v pin)
Using another computer
Swapping RX TX
Trying in different upload speeds
Holding RST button
Switching board between ESP32 Wrover Module and AI Thinker ESP32
I'm I doing something wrong or there's just something faulty?
I have delved for a solution in this regard for weeks and it seems I have a solution.
Findings-
FTDI module is probably faulty or not supported for each instance.
Aithinker Board is not compatible with esspressif (use ESP32Wrover, more details below )
I have an esp32cam from Esspressif, not Aithinker.
I was trying with FT232rl , No matter what Voltage/jumpers/USB cable I used, it didn't work. Always stuck with fatal timed out error.
After many futile attempts with FTDI breakout, I gave my Arduino UNO a try (please note my UNO has mega16u2 chip as USB serial chip (top right corner just beside the oscillator) and fortunately it worked.
I have read that CP2102 is also working.
**Here are the steps to follow-**
Arduino ESP32Cam connections
3.3 Arduino --------- 3v Esp32CAM
GND Arduino ------------ GND Esp32CAM
RESET Arduino to Ardunio GND
RX Arduino -------------- VOR Esp32CAM (this is not a mistake RX to rx & TX to tx)
TX Arduino -------------- VOT Esp32CAM
GPIO 0(zero)(written as IO0) Esp32CAM to GND Esp32CAM
I didn't have any need to press the reset button in any part of the operation before & during uploading.
I am assuming You have pre-installed the esp32 board manager.
Now select the correct COM port where your Uno (in this case) is
plugged in.
Select the correct board as mentioned
Tools>Board>ESP32 Arduino > select ESP32 Wrover Module
Some uploading setups are to be Done (Under Tools, these will only appear when the Wrover module is selected )
Upload speed -- 115200
Flash Frequency -- 40Mhz
Flash Mode -- QIO
Partition Scheme --- Huge App
Port ---- select the right com port for your breakout or UNO
JUST press upload and relax
After a while, you will be able to see this message
Leaving...
Hard resetting via RTS pin...
Disconnect the Esp32Cam GPIO 0 and GND
Power the ESP32Cam with 5/3v with external power supply (Arduino or other breakouts may not be able unless you are connected with a Powered USB Hub)
keep TX, RX, & GND of the 2 boards connected, don't disconnect Arduino Reset and GND.
Press Reset on ESPCAM and open Serial monitor and you will be able to see the IP address of the cam if it was configured with your wifi correctly.OR get any network scanner App on android or windows.
I hope it helped.
Pre-requisites for flashing:
ArduinoIDE 1.8.12
Core ESP32 1.04 (at time of writing)
Select board AI Thinker Cam
uplooad speed 921600
freq 240Mhz
flashfreq 80Mhz
mode QIO if not working try DIO
partition scheme default
Serial monitor is closed
NO hardware connected to the pins of the ESPcam
Make sure the USB cable is a data cable and NO loading cable only
check Windows device manager if programmer is shown and has max speed / 8n1 hardware
Connections
FTDI - ESP32
GND GND
5V 5V
TXD UOR
RXD UOT
If you use an AIThinker Cam clone you have to ground GIPO 0:
connect GPIO 0 with a dupont wire connected to GND
press reset
compile and upload (use AI THINKER CAM)
optional:
press reset
upload filesystem data (SPIFFS)
disconnect GPIO 0 and GND
press reset
code should execute
And yes you have to do it every upload, on my dev board I soldered a little switch with proper isolationSome more solutions from experience:
If there is still a problem use a 10K (or so) pull-down resistor between RX0 and GND (test on breadboard before soldering)
Pressing and holding (!) the boot-button while uploading on some "bad" boards
Happened with a "normal" ESP32 board to me - just to be sure - I got an ESP8266 in an ESP32 packaging. Configuring for the ESP8266 solved the issue of uploading.
In my case I forgot to remove the SD card. Other users recommended removing unnecessary connections to the pins-- and the SD card technically uses some of those :)
This was solved by using other jumpers. It seems one of the jumpers used in the wiring was faulty.
If you're having the same issue and tried everything in this post, try checking your cables!
Another solution here. Just to add, I tried everything on this QA, as well as many other things suggested online. e.g. tested by powering from 3.3V then 5V, various permutations of holding the reset button down and disconnecting IO00 from GND at the point of flashing. Changing various settings in Arduino IDE/
I was unable to flash a single one of the 5 ESP32-CAM boards I bought. Spent a good two hours on it. I even continuity tested every pin on the board to its ESP32 chip pad, and all the hookup wires were tested too. The board seemed fine.
Then I soldered a 100uF capacitor between 5V and GND, and used my USB-UART 5V power... tested and worked straight away. No need to pull out the IO00->GND connection and no need to press RST button on the board during flashing. (Of course, pull out IO00->GND after flashing complete.
So - it was a power problem.
I can only guess that the cheapo regulator they used on the copy of board that I got was not quite efficient enough, but basically that capacitor resolved the issue.
p.s. the ESP on board was marked "ESP32-S". I selected "AI Thinker ESP32-CAM" in Arduino IDE as suggested by most people online, and this worked.
There are 3 pins marked GND on the ESP32-CAM board. Buuuuut (!) the one marked GND/R just by the U0T is NOT connected to other grounds or anywhere else I could had find. Check with a multimeter and use a REAL GND. It just worked for me after days of puzzling.
If you try it with arduino it works but its needed to press reset button on esp32 before you upload your code
Basically I was facing the exact same problem fro quite some time. What worked for me was that as the chip was flashing, shifting the power wire from 5V to 3V3 pin. I do not know why but it workes. When esptool starts flashing at 2%, switching the cable just then, despite having 5V from supply into the 3V3 point made the flashing successful. I do realize this is probably a bad answer to your problem since it involves oversupplying voltage to the chip on the wrong point as it is flashing and could damage the chip. However, if anyone is tired of debugging and are at the point where you are considering throwing the chip away, might as well try my method. For other's who value their chip, don't try this method and if you still do, kniw it is at your own risk. But it worked for me after 3 days of just messing around with connections.

Any solution available for for ESP32-cam 'Brownout detector was triggered' error?

I had an ESP32cam working for a few days then started getting that message at boot up. Reloaded the program and still no camera.disappointed
Error:
ets Jun 8 2016 00:22:57
rst:0x1 (POWERON_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)
configsip: 0, SPIWP:0xee
clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00
mode:DIO, clock div:2
load:0x3fff0018,len:4
load:0x3fff001c,len:1216
ho 0 tail 12 room 4
load:0x40078000,len:9720
ho 0 tail 12 room 4
load:0x40080400,len:6364
entry 0x400806b8
Brownout detector was triggered
Serial monitor
Camera label:
HW-297
OV2640
In program:
#define CAMERA_MODEL_AI_THINKER
Board selection:
ESP32 Wrover Module
Board selections
Brownout detection is a hardware feature that shuts down the processor if the system voltage is below a threshold, also known as the "brownout voltage". This is to preserve memory contents and avoid corruption.
You are getting this message because your board is not correctly powered. The underlying reason could be one of many things:
The USB cable is of poor quality, or too long.
Your computer's USB port cannot supply enough power to the board.
The ESP32Cam is defective
Other components in your circuit are not correctly wired up, affecting the power supply.
I would try to power the ESP32Cam with another USB cable, a different computer, or an external 5V power supply. If all of that doesn't help, it could be that your board is broken.
Another option is to disable the brownout detector.
#include "soc/soc.h"
#include "soc/rtc_cntl_reg.h"
// in setup()
WRITE_PERI_REG(RTC_CNTL_BROWN_OUT_REG, 0);
I had this issue as well. I solved it by taking the following steps:
I originally had the ESP32-CAM powered off the 3.3V supply from my FTDI, but I then found it works better when supplied by 5V.
I had to jumper together the two pins marked in magenta to program the ESP32-CAM and then remove the jumper when I wanted the board to actually run:
I had to select the "AI Thinker ESP32-CAM" in the Board Manager:
i had terrible brownout issues. struggled for days - tried everything on the forums.
Solution - just connect the desktop power to the esp32-cam and all my troubles disapeared.
seems the esp32-cam runs so close to the 5v power limit, that 5v from a desktop power supply is required when connected to the computer's usb port. not quite enough power and that makes all the difference.
TLDR; Atfer programming, power the camera module from a good quality external 5v power supply, plugged into the 5v pin on the module. You should try to remember to disconnect the pwr from the programmer once programming is complete - the serial monitor will still work.
I had a similar experience to Clive, lots of problems when booting but in my case, the BROWN OUT message didn't always appear and often just the camera init failed.
In the end I powered the 5v pin on the module from a 5v supply and tried to remember disconnect the pwr pin from my 'FTDI' programmer. I forgot often and no damage appears to have occurred.
Every online guide I saw has pwr from the programmer going to the 5V pin on the module even though when jumpered for 3v3, the programmer VCC is at 3v3. I connected it to 3v3 on the module instead though this didn't fix the brownout issues.

doit 2-way motor & 16-way servo shield board

Got this board cheap from Banggood, but there are minimal details on how to use it.
There is a manual here https://www.gitbook.com/book/smartarduino/user-manual-for-2-way-motor-16-way-servos-shield/details , but it is a long way from detailed, and what I need are some details on how to drive the I2C PWM servos.
After some poking around, I have a partial answer.
The Adafruit libraries seem to work fine for the servos.
https://learn.adafruit.com/16-channel-pwm-servo-driver/using-the-adafruit-library
Motors on this version of the board have the following controls:
D6 PWMB - speed channel B
D7 DIRB - Direction Channel B
D8 PWMA - Speed Channel A
D9 DIRA - Direction Channel A
... which may explain why the speed control is working on channel B but not A, since pin 8 is not PWM on a UNO. (May also explain why it is cheap)
Also note that you need to supply a separate 5V to 18V power to the VS connector to drive the servos. I used a 6v battery pack.
Also note that the on-board power switch did not appear to affect power to servo, so a power switch for the servo power is probably also useful.
External power source is required only at VM & GND terminals if jumpers are shorted both at VM+VIN and VS+5V, VM will have the same voltage as input power and VS (servo voltage) will be 5V derived from VM input, not from UNO board. That is what the user manual means by single power source, which input is at VM terminal. OPEN all the jumpers will need individual power source for VM and VS separately.

Arduino Nano: is SPI supported?

Can SPI hardware on the Arduino Nano be used?
On the Nano page it says:
SPI: 10 (SS), 11 (MOSI), 12 (MISO), 13 (SCK). These pins support SPI
communication, which, although provided by the underlying hardware, is
not currently included in the Arduino language.
Yet there is an SPI library.
Please can someone explain this contradiction? I think, either
The nano page is out of date
SPI library is unsupported for the Nano SPI hardware but is supported on other boards
SPI library is implemented for the Nano in software only
Which is it?
Thanks
The correct answer is "some combination of the above":
Arduino Nano is based on the ATmega168/328 chip, which does support SPI in hardware.
The SPI library only supports hardware SPI (regardless of the Arduino model). Note that you could bitbang (relatively) slow SPI without any problems, this would be a relatively easy software implementation.
The status of SPI library should be considered same as the status of the Wire library: not part of core Arduino services (in contrast to PWM, ADC, and digital GPIO), but widely supported nonetheless.
So perhaps the closest answer in your multiple-choice question is "out of date". The status of SPI should look the same as the status of I2C.
This should be a comment but I haven't the rep.
As angelatlarge said, the SPI library is as supported for the Nano as it is for any of the other Arduinos. Except:
The Nano (like all Arduinos) has an LED attached to digital pin 13. Since, for the Nano, pin 13 is also SCLK for SPI, you may well run into trouble with high baud rates. If this is a problem for you, try removing the LED.
From the Nano's page: Source
...
SPI: 10 (SS), 11 (MOSI), 12 (MISO), 13 (SCK). These pins support SPI communication, which, although provided by the underlying hardware, is not currently included in the Arduino language.
LED: 13. There is a built-in LED connected to digital pin 13. When the pin is HIGH value, the LED is on, when the pin is LOW, it's off.
The Nano's product page is out of date, but it has the same hardware and software SPI support as the other ATmega168/ATmega328p-based Arduinos.
Some archaeology in the wayback machine reveals that the functionally comparable Duemilanove's product page was changed from a hardware-but-not-software mention to a mention of SPI library support between September 15th and 26th of 2010. When the Uno came out, its product page was based on the then-current state of the Duemilanvoe's, so it has always claimed support.
A corresponding update should have been made to the Nano page, but this appears to have been overlooked.

Resources