CCS SMT example builds but does verify

[JerryR]

Hello Group:

I have been experimenting with the SMT peripheral and started with the CCS example "ex_smt_period_duty.c". The only edit I made to this example is I'm using a PIC16F1619 instead of a PIC16F1618, so I used the appropriate include file.

I'm using CCS PCWH 5.120 to build. CCS ICD-U80 as debugger/programmer. Target is my design and programs, verifies, and runs with any other code.

The code builds correctly, but does not verify unless I comment out the two SMT-related interrupts.

CCSLoad reports correct voltage, and matched PIC devices. I have tried erasing manually with CCSLoad, same results, no verify.

Here's the code:

[temtronic]

While I don't use them ,I am curious... so I had a quik look at the 1618 and 1619... both have SMT and seem 'similar'....

Does the code verify with the 1618 PIC ?

Maybe look at the headers, compare and see if there's something 'different' about the 'SMT' sections ? I'd think they should be 100% the same ?

[JerryR]

Thanks for considering my post Temtronic!

I don't have a 1618 target to test verification, that would be a great experiment, however.

I do know if I just comment out the interrupts associated with the SMT, it builds and verifies. In all cases the code builds. When verification takes place, after programing, there is code there, just not what's expected.

Must have something to do with where the build places the interrupts. That's a great suggestion to check the device's header against the 1618.

Again, I appreciate your help!

[JerryR]

Thanks for considering my post Temtronic!

I don't have a 1618 target to test verification, that would be a great experiment, however.

I do know if I just comment out the interrupts associated with the SMT, it builds and verifies. In all cases the code builds. When verification takes place, after programing, there is code there, just not what's expected.

Must have something to do with where the build places the interrupts. That's a great suggestion to check the device's header against the 1618.

Again, I appreciate your help!

[Ttelmah]

Could you try going back to some older firmware on the ICD?.
There have been a number of issues with the latest updates to some of
the CCS ICD units not programming some chips/features correctly.
In the device editor, it might be worth trying changing the programming
method option. There are a lot of different options, and the more basic
options sometime work, but are slow, while the faster options are the ones
that are having problems.
It really does sound like a programming issue affecting some specific
part of the program memory, or some specific instruction.
It may only be a read problem. Does the code work if you disable verify?.
Have you tried with other interrupts enabled/present?. You might just
have a chip with a memory fault in the area used when the interrupts
are present.
I would suggest you talk to CCS about this. They seem to have been
tweaking the programming algorithms recently, and they are faster, but
seem to be giving a lot of issues.

[JerryR]

Hi Ttelmah:

Thanks for your interest!

Well, I do know that the code mismatches as far down as I can see after programming and I can get other code working well on the same target. Also, code does run if I compile and program with the two interrupts commented out.

I only have one ICD-U80, but it does seem to program other targets using different processors well. I do have several Microchip debuggers and programmers, but have really never been able to get CCS IDE to work with them.

To your suggestion, I'll try programming the troublesome target using Microchip Studio or an old version of MPLAB 8x before involving CCS. If I can successfully program with Microchip tools, I'll speak with CCS.

Thanks again my friend

[Ttelmah]

You missed part of what I suggested. Trying with another interrupt
enabled and coded. Has any of the other code you are trying got any
interrupts in use?.

[JerryR]

Yes! Absolutely, will do, thanks for the suggestion. I should be able to get back to this project early next week.

What's your theory? Vectors in wrong place? Sounds like a good learning experience.

Thanks again!

[JerryR]

Ttelmah:

To answer your question regarding adding any other interrupt. Yes, adding a Timer0 interrupt also causes a program not to verify.

I'll troubleshoot further next week.

Thanks,
Jerry

[sandyw]

Hello JerryR and Ttelmah,

Just wondering if there is any update on this is as I think I am seeing the same thing with my code.
I'm using:
CCS compiler Vers 5.116,
ICD U80 Firmware 3.64
PIC processor pic16F18146

I have programmed in an absolute minimum program shown

< Header File>
#include <16F18146.h>

#fuses NOLVP

#device ADC=12 ICD=true
#use delay(internal=16000000)

#define LED PIN_C7
#define DELAY 1000

<Main file>
#include <main.h>

void main()
{

while(TRUE)
{

//Example blinking LED program
output_low(LED);
delay_ms(DELAY);
output_high(LED);
delay_ms(DELAY);

//TODO: User Code
}

}

#int_timer1
void timer1_isr(void)
{

}

It will compile and run with out the interrupt routine directive. As soon an you include the #int_timer1 it fails to verify. It is not unique to the #int_timer1 directive. It fails to verify with all of the #Int_XXXX I've tried including int_rda, int_timer0, int_ext.

Any news on your problem JerryR

Ttelmah you said "In the device editor, it might be worth trying changing the programming method option." Not sure what you mean by this, how do you change the programming method option?

Thanks for any help

SandyW

[sandyw]

Some more information.

I am using exactly the same set up as before but now programming our usual micro the pic18f8722 and everything is working as normal.

SandyW

[JerryR]

sandyw, Ttelmah:

Well, I solved the issue, but am still very puzzled by the solution.

After, closely examining my power supply with a scope, I noticed, that if I compiled the code with any interrupts coded in, the power at the microcontroller's Vdd pin, became slightly more noisey during programming verification. Why, I hadve no idea, except to believe the code begins to run at verification.

To sove the issue, I placed an additional 10uF tant at the controller's Vdd pin in addition to the 0.1uF already there. I assume that the controller might draw a bit more current with the interrupts coded in. Just a guess.

In years of PICing, I have never experienced this before. I'm open to further study, but I'm moving ahead with the project.

When in doubt add a bigger bucket of charge to the controller.

[sandyw]

JerryR,

Thanks for the Reply. I'll give it a go and see.

Sandy

[temtronic]

Ouch... you added a tantalum cap ??? I had several of them 'meltdown' decades ago on a very pricey custom PCB ( $2500). nasty little blobs.... Heard they can be 'troublesome'.

Since then, just use 'standard aluminum' caps.....
I also design PSU to be x10 the nominal rated current( say 1 amp.... use a 10 amp PSU ). Firm believer in 'over kill', saves the headache of trying to troubleshoot at 3 AM. Also allows for that 'just two more LEDs' to be added without 'weird' stuff happening !

[sandyw]

All good info, thanks

SandyW