The code I uploaded before the board started become unresponsive, this code is stuck in my board and it's still spitting out data on the Serial Monitor: myrfid.ino from this website
I'm hitting a roadblock, I have no idea what to do next
There is a known bug in Arduino IDE 2.x that causes uploads to fail with this "Access is denied" error if you try uploading to a board using an FTDI FT232R USB chip while the Arduino IDE Serial Monitor or Serial Plotter is open.
A port can only be used by one process at a time, so Arduino IDE must automatically close the port in Serial Monitor and Serial Plotter during an upload, automatically opening it again after. For some reason, that juggling of the port control is not working with boards that have the FTDI USB chip.
If that bug is the cause of the problem you are having, the workaround will be to manually close the port in Serial Monitor/Serial Plotter before doing an upload. Please give that a try and then let me know if you still have the error while uploading:
Serial Monitor
Click the X icon on the "Serial Monitor" tab in the bottom panel of the Arduino IDE window to close the tab:
Open Serial Monitor again if needed (by clicking the icon on the IDE toolbar or the Tools > Serial Monitor menu item) after the upload is finished.
Serial Plotter
If you have the "Serial Plotter" window open, the procedure is a bit different from closing the Serial Monitor connection:
Close the "Serial Plotter" window.
If the "Serial Monitor" view is not already open, select Tools > Serial Monitor from the Arduino IDE menus to open it. ⓘ We must do an open/close cycle on Serial Monitor as a workaround for a bug in Serial Plotter
Click the X icon on the "Serial Monitor" tab in the bottom panel of the Arduino IDE window to close the tab:
Okay, thank you! I've installed both drivers now
Also followed @ptillisch steps, it does get rid of the Access Denied error now but now, when I upload my sketch, it doesn't throw an error, it just resets and keep the old sketch
When the "Verify code after upload" preference is enabled, after finishing an upload Arduino IDE reads the memory on the Arduino board and compares the read data against the data of the compiled sketch binary file on your computer that was uploaded to the board. When it did that, it found that the data on the Arduino board did not match what should have been there. This means the uploaded program was not written to the memory in the Arduino board during the upload process as expected.
It is possible that a short or external circuitry connected to the Arduino board could cause this type of problem by interfering with the upload process.
Make sure the board is not sitting on anything conductive that could short the contacts on the bottom of the board. Make sure there isn't any conductive debris (e.g., strands of wire or component leads) on the board or on the surface the board is sitting on.
If you have another USB cable on hand, try changing the cable. Maybe a damaged or defective USB cable could be the cause. Make sure the USB cable is fully inserted into the USB socket on the board and computer.
If you have a shield or any external circuitry or components connected to your Arduino board, try this experiment:
Disconnect the USB cable of the Arduino board from your computer.
Disconnect any shields, modules, external circuitry, etc. from your board.
Connect the Arduino board to your computer with a USB cable.
Now try uploading a sketch to the board again. Does the upload succeed?
This experiment will determine whether the upload error was caused by interference from your external circuitry. If so, you can then focus your attention on identifying the specific problem with the circuit and resolving it.
Some users who experienced unexplained upload failures at the verification step reported that the problem was resolved by performing a "Burn Bootloader" operation on the board.
A program called a "bootloader" is stored in a special area in the microcontroller's memory. This program receives the sketch program upload data from the computer and writes the data to the program memory. When you perform a "Burn Bootloader" operation, you upload a new copy of the bootloader program to the microcontroller.
It is not clear what could cause the bootloader program to be corrupted in a manner that allows it to communicate with the computer as usual, but fail to write to program memory, without the microcontroller having suffered physical damage (which can not be fixed by a "Burn Bootloader" operation). However, if it has apparently helped others to restore their boards to a usable condition, burning the bootloader might be worth a try.
I know that unfortunately you have been experiencing some strange failures when you tried to perform a "Burn Bootloader" operation. However, I saw that the last time you tried it, the chip was correctly identified as an ATmega328P, and the upload only failed because you had the IDE configured for ATmega32 (which was reasonable since the chip had been identified as ATmega32 previously).
So I suggest you connect your "Arduino as ISP" programmer back to the non-functional board, select Tools > Board > Arduino AVR Boards > Arduino UNO from the Arduino IDE menus, and try another attempt at "Burn Bootloader". Hopefully whatever problem (possibly a corruption of the communication between the boards caused by a poor connection in the wiring?) caused the chip to be misidentified the last time you tried that has somehow been resolved since then and the "Burn Bootloader" operation will succeed this time.
Very odd that you get a signature from a Atmega32 out of that TQFP-32 package. The Atmega32 has 44 pins, not 32. Yours looks like the normal Atmega328P.
Maybe its just bad serial (SPI) communication and the last byte gets changed. But that's just a wild guess and you tried different cables, USB ports, etc. already.
My question now is how do I fix the bootloader so it would accept the sketch when I'm using Board > Arduino AVR Boards > Arduino UNO, or do I have to rely on this MiniCore library whenever I want to upload to this specific board?
It's not a library, it's a board package. And yes, you have to rely on that.
There is no reason to be adverse to the use of Minicore. And the 328PB is actually a better processor. But of the manufacturer of your board is aware of that is another question.
This procedure is not intended to solve the problem. The purpose is to gather more information.
