Help with DSPIC33EP512MC806

[trastikata]

Hello all,

I am trying to get a simple LED to blink using DSPIC33EP512MC806 however unsuccessfully thus far. Just to make sure, I've read back the FLASH memory after flashing and compared to the original file and everything matches.

Schematic is very simple and the LED is connected to PORTF.3, the code relies on internal 7.37 MHz FRC. I've been looking at datasheet for two days now and I can't find a reason why it shouldn't work ...

Code Select Expand

Device = 33EP512MC806
Declare Xtal = 8
Declare Auto_Heap_Arrays = On
Declare Auto_Heap_Strings = On
Declare Auto_Variable_Bank_Cross = On
Declare Stack_Expand = On
Declare Watchdog = OFF

Symbol LED = PORTF.3

Main:
    'Set all digital
    ANSELB = 0 : ANSELC = 0 : ANSELD = 0 : ANSELE = 0 : ANSELG = 0
    Output LED : Low LED
   
    While 1 = 1
        DelayMS 1000 : High LED
        DelayMS 1000 : Low LED
    Wend
End
   
'-------------------------------------------------------------------------------
'**** Added by Fuse Configurator ****
Config FGS = GSS_OFF, GSSK_OFF, GWRP_OFF
Config FOSCSEL = FNOSC_FRC, IESO_ON
Config FOSC = FCKSM_CSECME, IOL1WAY_OFF, OSCIOFNC_ON, POSCMD_NONE
Config FWDT = FWDTEN_OFF, PLLKEN_OFF, WDTPOST_PS16384, WDTPRE_PR128, WINDIS_OFF
Config FPOR = ALTI2C1_OFF, BOREN_OFF, FPWRT_PWR1
Config FICD = ICS_PGD2, JTAGEN_OFF, RSTPRI_PF
Config FAS = APL_OFF, APLK_OFF, AWRP_OFF  
'**** End of Fuse Configurator Settings ****
'-------------------------------------------------------------------------------


[John Lawton]

Have you tried:

Code Select Expand

Symbol LED = LATF.3John

[John Lawton]

Also, on this datasheet: https://www.farnell.com/datasheets/1669518.pdf

"Pull-ups and pull-downs on change notification pins should always be disabled
when the port pin is configured as a digital output".

But maybe interrupts are disabled.

Have you tried other posts/pins?

John

[John Lawton]

Oops, more. Page 218 of the above datasheet:

"Most I/O pins have multiple functions. Referring to
the device pin diagrams in the data sheet, the
priorities of the functions allocated to any pins are
indicated by reading the pin name from left to right.
The left most function name takes precedence
over any function to its right in the naming conven␂tion.
For example: AN16/T2CK/T7CK/RC1; this indicates that AN16
is the highest priority in this example and will supersede
all other functions to its right in the list.
Those other functions to its right,
even if enabled, would not work as long as any
other function to its left was enabled. This rule
applies to all of the functions listed for a given pin.
Dedicated peripheral functions are always higher
priority than re-mappable functions. I/O pins are
always the lowest priority."

In your case I think you are using RP99/RF3, so is the RP99 active?

John

[trastikata]

Thank you for your input John. I've found the culprit ...

MPLABX IPE has an option to either hold in reset or release the device from reset after flashing, it is in the settings menu. I am aware of it and this was the first thing I checked. However it seems that for this device DSPIC33EP512MC806, PICkit3 does not release it from reset state, although the MPLAVX IPE gives the message that the device is released.

I've just found it by accident after turning the PCB on to try some more ideas but forgot to connect the PICKit3 ICSP header and the LED started blinking. After a weekend spent in soldering and de-soldering and cursing ... what a waste of time. 



Newer versions of MPLABX IPE might have fixed that but after version 6.20 they don't support PICKit3.

But to answer your questions.

- High and Low PORTx commands involve LATx in the resulting assembler code, however I tried this too.
- PORTF on this device has no other functions than digital IO, RP99 means it is available to the PPS module either as input or output, so no analog or other special functions.
- PORTF.3 is available for open drain function but this I've tried too.

This bug almost brought crazy, I checked PCB traces, power supply and everything and should have worked .... I was on the bring to start decoding hex code 

[John Lawton]

Glad to hear that you found the culprit!

John