So I decided to check files generated by Flowcode V4 and V5Working Around Config. Problems with PIC18F13Kxx
People are having a problem getting the new 18F13Kxx devices to program correctly. If
you use the new Pickit3 programmer everything works fine but most other programmers
are having a problem. It seems the issue is with a set internal debug ON/OFF flag and
Microchip have done a poor job of documenting this issue. The new Pickit3 programmer
automatically handles this flag and sets the internal debugger off so when the device is
operating the user's firmware works.
The real problem however is this flag is not included in th e MPLAB device config files,
so any PPI or config routines in various PIC18 compilers never set the config register
correctly. You're stuck between a rock and a hard place. Until Microchip get their act
together and include the functionality in MPLAB, the compiler manufacturers can never
get their configuration files sorted.
I called Microchip about this issue and here is their reply.
"I checked with our apps group in Chandl er supporting this product line. Bit 7 of
CONFIG4L is not unimplemented; it is the Background Debug bit. The PIC18F1xK22
has an on chip debugger therefore the BKBUG configuration bit MUST be programmed
to 1. Not doing so would enable the debugge r. The documentation may not state this
clearly, so they are going to review it. But if your compiler do es not set this bit then the
chip will not function correctly..."
Tweaking the PPI and def files in the compiler cannot add the debug option to the
18F1xK22 series. All PPI files are built from Mchip INC files, so if the fuse is not in the
INC file it will never make it into the compiler’s PPI file. Worse, if the fuse settings are
not in the Mpasm INC file, then even if you add them to the PPI file they may be rejected
by the assembler MPASM. It’s a debug flag th at is only normally set / required when
doing debugging (via the Pickit3).
A workaround in the Proton PDS compiler is to disable the compiler's normal
configuration setup and then us e assembler instructions to add custom fuse values. The
following is an example that user feedback has confirmed as definitely working for the
18F13K22.
Instead of the normal 'ConfigStart-ConfigE nd' instructions in Proton PDS place the
following:
===============================================================
Code:
@ CONFIG_REQ = 0 ; Disable the compiler's configuration setup
Asm-
'
' Add custom values for fuses
'
__config config1h, 0xE8
__config config2l, 0x19
__config config2h, 0x1E
__config config3h, 0x00
__config config4l, 0x81
__config config5l, 0x03
__config config5h, 0xC0
__config config6l, 0x03
__config config6h, 0xE0
__config config7l, 0x03
__config config7h, 0x40
Endasm-
You do not have to add anything else to the code, the program runs perfectly. The $81 in
config4L takes care of bit 7.
On looking at the data sheet for the 18F13K50 it appears to have the same problem flag
i.e. bit 7 of the CONFIG4L register. Th is is specified as the BKBUG Background
Debugger Enable bit and a 1 disables the debugger and a 0 enables it. However, 'Note 1'
in the data sheet clearly state that this bit is only for the ICD device. Otherwise this bit is
UNimplemented and read as '1'. This is clearly wrong information. The bit IS
implemented at programming and the programmer n eeds to specifically set the bit to a '1'.
Failure to take this into consideration will re sult in the bit being read as a '0' causing the
background debugger to be implemented when the device is running. The end result is
that your firmware will not run correctly because it is doing background debugging. You
must physically set the BKBUG Background Debugger Enable bit to a '1' during
programming and the only way currently to do this is to use a Pickit3 programmer or
add the above ASM routine into Proton PDS before compiling your code
This is my reply back:
"Thanks for the information.
I have just checked the hex file and it looks like FC4 and FC5 do set the correct bit to 1 (Bit7 in config 4)
Note: Hex coloured red is the Config Byte (CFG4L) in question. since 0x88 = 0b10001000 you can see Bit 7 correctly set.
Hex:
:0E000000FFE21F1EFF0888FF03C003E003405D
Also generated ASM and C also looks correct,
ASM:
ORG 0x00300000
DW 0xE2FF
DW 0x1E1F
DW 0x08FF
DW 0xFF88
DW 0xC003
DW 0xE003
DW 0x4003
The Red 88 is Config 4 Low which is Background Debug Disabled, So this is correct.
C code:
/Configuration data
#ifdef _BOOSTC
#pragma DATA 0x300000, 0xff
#endif
#ifdef _HI_TECH_C
%C__CONFIG(%A, %V);
#endif
#ifdef _BOOSTC
#pragma DATA 0x300001, 0xe2
#endif
#ifdef _HI_TECH_C
%C__CONFIG(%A, %V);
#endif
#ifdef _BOOSTC
#pragma DATA 0x300002, 0x1f
#endif
#ifdef _HI_TECH_C
%C__CONFIG(%A, %V);
#endif
#ifdef _BOOSTC
#pragma DATA 0x300003, 0x1e
#endif
#ifdef _HI_TECH_C
%C__CONFIG(%A, %V);
#endif
#ifdef _BOOSTC
#pragma DATA 0x300004, 0xff
#endif
#ifdef _HI_TECH_C
%C__CONFIG(%A, %V);
#endif
#ifdef _BOOSTC
#pragma DATA 0x300005, 0x8
#endif
#ifdef _HI_TECH_C
%C__CONFIG(%A, %V);
#endif
#ifdef _BOOSTC
#pragma DATA 0x300006, 0x88
#endif
#ifdef _HI_TECH_C
%C__CONFIG(%A, %V);
#endif
#ifdef _BOOSTC
#pragma DATA 0x300007, 0xff
#endif
#ifdef _HI_TECH_C
%C__CONFIG(%A, %V);
#endif
#ifdef _BOOSTC
#pragma DATA 0x300008, 0x3
#endif
#ifdef _HI_TECH_C
%C__CONFIG(%A, %V);
#endif
#ifdef _BOOSTC
#pragma DATA 0x300009, 0xc0
#endif
#ifdef _HI_TECH_C
%C__CONFIG(%A, %V);
#endif
#ifdef _BOOSTC
#pragma DATA 0x30000a, 0x3
#endif
#ifdef _HI_TECH_C
%C__CONFIG(%A, %V);
#endif
#ifdef _BOOSTC
#pragma DATA 0x30000b, 0xe0
#endif
#ifdef _HI_TECH_C
%C__CONFIG(%A, %V);
#endif
#ifdef _BOOSTC
#pragma DATA 0x30000c, 0x3
#endif
#ifdef _HI_TECH_C
%C__CONFIG(%A, %V);
#endif
#ifdef _BOOSTC
#pragma DATA 0x30000d, 0x40
#endif
#ifdef _HI_TECH_C
%C__CONFIG(%A, %V);
#endif
So im not sure if there is even an issue with PIC18F13Kxx devices with Flowcode?
I did notice that MPLAB does not show Debug option within configuration screen, and that's the only bug I can find.
Hope this helps."
Since I Don't believe there is an issue with Flowcode and is just an issue with microchip?
If someone who has got this device (or who has more knowledge then me) could confirm if I am correct or not please?
I.e use Flowcode to send a program to chip after setting correct configuration settings, and see if hardware is working and Debug Mode is indeed disabled.
That It would be appreciated and also will be helping others with these devices out.
Thank you
Martin