My PIC 24 is Halting - Page 1
Forum section: electronics / general

author: Ground_Loop
author_rank: Frequent Contributor
timestamp: January 03, 2023, 02:33:23 am
content: This is a completely new thing to me. I've never had a microcontroller just spontaneously stop running. The clock still runs, but will not execute code or even respond to interrupts. Further, and stranger still is that the micro in my development environment is the one that is halting. The one in the final application runs just fine.I got into the debugger in MPLAB and discovered with the help of the MCC traps code that I'm getting address errors and sometimes stack faults. I've tried adding code to recognize and push through the problem to no avail. It just hangs until I do a full power down reset.The development environment is on a solderless breadboard with two other micros running in the vicinity, a PIC16 and a PIC18. The actual application is on a proper board in an enclosure and nowhere near the two other micros. This all came about when I swapped out the primary micro for another with nearly identical configuration, but more memory (PIC24FJ for a PIC24FV). Between the three running micros I have numerous comm peripherals all running at fairly low frequencies. I've tried to nail it down to a particular region or function call, but it appears completely random. I have some spare micros that I've tried but they all exhibit the same behavior. Is it possible that there is some cross talk causing this?

author: Tomorokoshi
author_rank: Super Contributor
timestamp: January 03, 2023, 02:40:29 am
content: 1. Check for noise on MCLR and power.2. Is it the same binary in both environments? Same compiler options?3. How old is the compiler? Any updates from Microchip?

author: Salome2
author_rank: Regular Contributor
timestamp: January 03, 2023, 02:47:05 am
content: 24FJ Vdd max =3.6V 24FV Vdd max>5VLack of bypass cap Vdd-VssFloating IRQ pin TRIS'd as inputFloating Reset pinGround Loop

author: Ground_Loop
author_rank: Frequent Contributor
timestamp: January 03, 2023, 03:27:44 am
content: Power supply was changed to 3.3V. I was running it at 3.6 due to some other devices, but lowered it to 3.3. Didn't help.Computer is new running latest MPLAB and compiler versions fully updated. Programmer is PicKit4.Same code on both systems.MCLR has proper pull upAll power pins bypassed with 100nF.No floating inputs.I'm beginning to suspect PS noise. Also considering UART buffer overflow. There are rumblings of UART issues with PIC24s.

author: Salome2
author_rank: Regular Contributor
timestamp: January 03, 2023, 03:37:55 am
content: What about Ground loop?MCU pin being UV'd <-.3 or OV'd >3.6V by connected circuitry?Bent pin of MCU inserted in B-board/bad connectionw to resistor/MCU pin to B-board.

author: Ground_Loop
author_rank: Frequent Contributor
timestamp: January 03, 2023, 11:53:15 am
content: I'll check on ground loop as well. Ground is spiderwebbed all over a very large board.

author: voltsandjolts
author_rank: Unknown
timestamp: January 03, 2023, 01:57:31 pm
content: Quote from: Ground_Loop on January 03, 2023, 02:33:23 amSolderless breadboard, yuk.Dodgy contacts?Jumper wires like a ball of fishing line?

author: Ground_Loop
author_rank: Frequent Contributor
timestamp: January 04, 2023, 04:33:09 am
content: Quote from: voltsandjolts on January 03, 2023, 01:57:31 pmThe development board is a high quality Global Specialties 105 board with all wires cut to proper length and formed to path. If I wasn't out of town I'd attach a pic. But yea, solderlesss breadboard.

author: JPortici
author_rank: Super Contributor
timestamp: January 04, 2023, 07:20:10 am
content: Quote from: Ground_Loop on January 03, 2023, 02:33:23 amI have never experienced stack faults in 16bit PICs.I have experienced many address faults, but they were the result of runaway pointers or stack overflows in RTOS tasks.But i would agree with the others and say that your development environment is at fault. I would inspect the power supply, strange things can happen (including hardware faults) if VDD and VCAP are not rock solid and free from EMI. PIC24 are particularly subsceptible to EMI, at least compared to 8bit PICs that could survive a nuclear blast.I would toss the breadboard and grab one of the working boards and do development there.Quote from: Ground_Loop on January 03, 2023, 03:27:44 amnot that i know of. Or at least, nothing insurmuntable and nothing that would cause hardware traps.

author: TomS_
author_rank: Frequent Contributor
timestamp: January 05, 2023, 09:33:32 am
content: Does the problem still exist if you go back to the original PIC in your dev environment?If you can see that you are getting address errors, can you also see which instruction is causing it? That information should be available as part of the exception and will help you figure out what is causing it. This information may be placed onto the stack as part of handling the error.Address errors can be caused by trying to read or write a word to an odd address, so it would pay to look at your code for any pointers that operate on word or greater data sizes (2+ bytes, like 16 or 32 bit integers) and make sure those pointers are not trying to access odd addresses.I don't know if the PIC24 compiler has the same features, but for PIC32 there are such things as conditional software breakpoints, basically assert statements that cause a software breakpoint to be executed, but you can use these to help track down all kinds of problems. If you do some pointer arithmetic you can follow it up with one of these to ensure that e.g. the least significant bit in a pointer is not set (i.e. you are only accessing even addresses). I sprinkle these through my code to help catch uninitialised pointers or illegal values during development. They are compiled away during a production build so don't have any impact on performance.I recently had a really head scratching issue in a project. It (seemingly) worked fine in debug mode but failed in production mode. Turns out I missed one = in an if statement in a comparison (basically made it a useless assignment instead). I don't know how or why it seemed to work in debug mode, but it was causing the PIC to constantly reboot. Probably not the same but the most mundane and unexpected things can catch you out sometimes. That's when I realised that the PIC32 compiler has very few warnings enabled by default, which would have helped me catch it sooner... Lesson learned!

author: Brianf
author_rank: Regular Contributor
timestamp: January 05, 2023, 09:54:16 am
content: What capacitor is connected to Vcap?

author: JPortici
author_rank: Super Contributor
timestamp: January 05, 2023, 03:00:41 pm
content: Quote from: TomS_ on January 05, 2023, 09:33:32 amBut it's using an old version (oooooooooold version) of GCC which has few intelligent warningsThat is more the job of a static analyzer. cppcheck is fine if you don't want to pay for it

author: Ground_Loop
author_rank: Frequent Contributor
timestamp: January 07, 2023, 11:22:45 pm
content: Quote from: Brianf on January 05, 2023, 09:54:16 am10uF tant.

author: Ground_Loop
author_rank: Frequent Contributor
timestamp: February 07, 2023, 12:43:35 am
content: Well, I figured it out. A few rookie mistakes, and not associated with programming or compiler. First, I had debounce caps across the pull down resistors for the input pushbuttons without current limit resistors. Second, when I changed the power supply for the new micro from 5V to 3.3V I did not change the pushbutton voltage (other components still required 5V). I beefed up all the ground rails such that at no point is there more than 4mV drop. Lastly, and most significant, I used a cheap noisy buck block from Amazon for the 3.3V supply. I replaced it with a nice quiet linear power supply. Once I made all the changes it works flawlessly.