support added for K40 devices

Coding and general discussion relating to the compiler

Moderators: David Barker, Jerry Messina

Jerry Messina
Swordfish Developer
Posts: 1469
Joined: Fri Jan 30, 2009 6:27 pm
Location: US

Re: support added for K40 devices

Post by Jerry Messina » Thu Jan 05, 2017 7:17 pm

There's an important errata for the K40 family regarding the use of TBLRD instructions.
This would effect many string and array operations, as well as a bunch of library code.
This has been fixed in the latest silicon, but if you're like me you ended up with the first batch with the bug!

Copy the following code to a file (ie 'K40_errata.bas') and place it in your userlibrary folder.
K40_errata.bas:

Code: Select all

module K40_errata

//
// **note**: include this module first before ANY others since it
// must execute before any other startup code that uses TBLRD
//
// Errata for the K40 family:
// TBLRD requires NVMREG value to point to appropriate memory
//
// The affected silicon revisions of the PIC18FXXK40 devices improperly require the 
// NVMREG<1:0> bits in the NVMCON register to be set for TBLRD access of the various 
// memory regions.
// The issue is most apparent in compiled C programs when the user defines a const type
// and the compiler uses TBLRD instructions to retrieve the data from program Flash memory.
// The issue is also apparent when the user defines an array in RAM for which the complier 
// creates start-up code, executed before main(), that uses TBLRD instructions to initialize
// RAM from PFM.
//
// Work around
// Set the NVMREG<1:0> bits to select the appropriate memory region before executing
// TBLRD instructions.
//
// If there is a need to change the NVMREG<1:0> value to anything other than 0b10 and 
// the Interrupt Service Routine uses constants or literal strings, then interrupts must
// be disabled before the change and restored to 0b10 before interrupts are enabled.
//
// In other words:
// You will have to change NVMCON1bits.NVMREG to access User ID, configuration bits, 
// Rev ID, Device ID or Data EEPROM. If you do any of things, be sure to change it back to 0b10
//

public inline sub k40_nvm_errata()
    asm
        ;NVMCON1 is located in the access bank, so no banksel reqd
        bsf NVMCON1, 7      ;NVMREG1
        bcf NVMCON1, 6      ;NVMREG0
    end asm        
end sub

k40_nvm_errata()

end module

When you use this, you MUST add it as the first 'include' in your program...

Code: Select all

program main
device=18F27K40

include "K40_errata.bas"

//<other includes go here>

end program
You could also just add the 'include "K40_errata.bas"' statement to the end of the device .bas file and that way it'll always be included automatically for you.

bitfogav
Registered User
Registered User
Posts: 169
Joined: Sat Oct 09, 2010 1:39 pm
Location: United Kingdom

Re: support added for K40 devices

Post by bitfogav » Fri Jan 06, 2017 6:33 pm

Thanks for posting the info above and the eeprom issue Jerry.

Jerry Messina
Swordfish Developer
Posts: 1469
Joined: Fri Jan 30, 2009 6:27 pm
Location: US

Re: support added for K40 devices

Post by Jerry Messina » Wed Jan 11, 2017 11:53 am

I've updated the PPS module to v1.41 to incorporate a datasheet errata with the 24K40/25K40 and PPS output mapping


UPDATE: seems there was a typo in the version I originally uploaded, so be sure to get the latest copy!

SHughes_Fusion
Posts: 219
Joined: Wed Sep 11, 2013 1:27 pm
Location: Chesterfield

Re: support added for K40 devices

Post by SHughes_Fusion » Tue Aug 08, 2017 8:21 am

I could be being thick here, but how does PPS work on the K40s?

For outputs, the datasheet has a column for 'Device Configuration' which isn't explained anywhere - is this showing the ports those peripherals can be mapped to? From other PPS devices I've looked at outputs can be mapped to any PPS pin so does this mean the K40 has a limited PPS implementation?

Also, am I right in thinking I can map an output to multiple pins?

I'm planning a device where I need lots of PWM outputs and wondering if the K40 could be used in place of a dedicated chip such as the PCA9685. I know I'll be limited in terms of variation of output settings to the number of PWM modules on the chip, but that's not a problem in this application. It's controlling multiple LEDs but where only a few will be on at any one time.

Jerry Messina
Swordfish Developer
Posts: 1469
Joined: Fri Jan 30, 2009 6:27 pm
Location: US

Re: support added for K40 devices

Post by Jerry Messina » Tue Aug 08, 2017 9:42 am

the datasheet has a column for 'Device Configuration' which isn't explained anywhere - is this showing the ports those peripherals can be mapped to?
That's the way I understand it. You basically get a choice of mapping a peripheral to any of the pins on 2 ports... say PORTB and PORTC for TMR0, so you get a choice of up to 16 pins. I don't know what would happen if you tried to assign the TMR0 output to a PORTA pin... they don't say.

It's not as flexible as the full PPS crosspoint found on some chips but it's a heck of a lot less confusing than the PPS Lite module found in the J94. On that one while you get a choice of more ports, the pins you can select are fixed. That one had me sweating bullets when I laid out that board!

I haven't tried it on the K40, but I don't see any reason why you couldn't assign an output to multiple pins.

Did you get your TMR interrupt sorted out?

SHughes_Fusion
Posts: 219
Joined: Wed Sep 11, 2013 1:27 pm
Location: Chesterfield

Re: support added for K40 devices

Post by SHughes_Fusion » Tue Aug 08, 2017 2:27 pm

Thanks, Jerry, good to know someone agrees with my interpretation. Would be better if they were a bit clearer though. Microchip datasheets have always had areas where they weren't too clear but they appear to be getting worse of late.

Sorted one timer issue only to hit another... I had forgotten to enable the timer interrupt.... :oops: :oops: :oops:

Tried using Compare as was suggested and it only took me a few minutes to realise it wasn't working because I needed to synchronise with the system clock.

Now I can't work out why logged and measured times don't quite tie in. All good fun!

Post Reply