Confused, Hardfaults, but clock enabled?

[xxxajk]

MCU: MKE16F512VLH16

Working on some bare metal code here, not using any of the prepackaged drivers, and can't seem to get LPSPI, and a few other of the components working. All seem to be related to FIRCDIV2.

Here is my register dump.

SCG_FIRCCSR 0x01000001 No error, not sysclk, valid, enabled
SCG_FIRCDIV 0x00000201 FIRCDIV2 /2, FIRCDIV1 /1
SCG_FIRCCFG 0x00000000 48MHz
SCG_FIRCTCFG 0x00000000 N/A
SCG_FIRCSTAT 0x00002353 N/A

SCG_SPLLCFG 0x00040201 *20, prediv /3, source = Fast IRC(48mhz)
SCG_SPLLCSR 0x03000001 SCS Fast IRC, DIVCORE /1, DIVBUS /1, DIVSLOW /2
SCG_SPLLDIV 0x00000101 plldiv2 /1, plldiv1 /1

PCC_LPSPI0 0xc3000000 Present, enabled, FIRCDIV2

PCC_LPI2C0 0xc3000000 Present, enabled, FIRCDIV

PCC_FTM0 0xc3000000 Present, enabled, FIRCDIV

SCG_SIRCDIV 0x00000101 div 2 /1, div 1 / 1

SIM_CHIPCTL 0x00008040 can filter SIRC clock, CLKOUT Select LPO clock (128kHz)

SCG_RCCR 0x03000001 SCS Fast IRC, DIVCORE /1, DIVBUS /1, DIVSLOW /2
SCG_HCCR 0x06000017 SCS System PLL, DIVCORE /1, DIVBUS /2 , DIVSLOW /8

Basically...

CORE_CLK 160MHz
SYS_CLK 160MHz
BUS_CLK 80MHz
FLASH_CLK 20MHz

So far...
ADC 24MHz Works!
SPI 24Mhz Hardfault
I2C 24MHz Hardfault
UART 24MHz Not tested yet, will probabbly hardfault.
FLEXIO 24MHz Not tested yet
LPIT 160MHz Works!
LPTMR 160MHz Works!
FTM 160MHz Works!
CAN 80MHz Works!

So it would seem to me that FIRCDIV2 isn't working, even though the bits are set? What am I missing?

[workalot]

Hello - I am drawn to offer this reply as I also suspect issues with the 'holes'/'gaps' in the peripheral register space.

Like you I prefer a more direct IDE. I am using the EmBitz IDE to explore the MK66 MCU.  My issue is the showing of peripheral registers during a debug session. The SVD file (as far as I can tell) is accurate, yet most peripheral registers are not readable.

The few peripherals that do show content seem to have contiguous register space (eg FTFE).

This a comment only reply.

Workalot 

[mjbcswitzerland]

Hi

Use IAR Kickstart version. It is free and gives very good register viewing (much more practical and faster than the Eclipse based ones like MCUXpresso). You can still develop in EmBitz but simply connect from IAR to do that part of the work that it isn't suitable for yet - submit such bug reports to the IDE developers so that the can maybe solve such things for the future (IDE's debugger engine should handle non-accessible memory by displaying it accordingly).

Regards

Mark

[Hui_Ma]

Hi，

From the KE16F high-level clocking diagram, the ADC module also using the same clock source from FIRCDIV2_CLK.

While, from your test result, the ADC 24MHz works.

So, I think the clock setting without any problem.

I would recommend customer to download MCUXpresso SDK for TWR-KE18F board and test [lpspi] demo.

..\boards\twrke18f\driver_examples\lpspi

Thank you for the attention.

Have a great day,
Mike

-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

[xxxajk]

Got the demo to compile after way too much effort. It isn't yet revealing any secrets register-wise...

Still digging...

[Hui_Ma]

Which IDE software you are using?

You don't need to porting the KE18 project to KE16, which are using the same product platform.

You can debug the KE18 project at KE16 chip platform.

Please just compare the register value difference.

Wish it helps.

Have a great day,
Mike

-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

[xxxajk · Accepted solution]

Problem confirmed! I can't just simply memcpy()/DMA to/from a struct to/from some peripheral register sets.

Instead I need to access each register separately, do it the hard way and copy one register at a time.

Perhaps the documentation should include these gaps with a note stating to not access them or a hardfault will occur.

[mjbcswitzerland]

Hi

Access to none existing memory will always result in a hard fault. Holes and gaps in peripheral space are non-existent memory locations, so will hard fault if attempted.

Quite a lot of peripheral areas don't have holes and so complete register sets can be copied using memcpy() or using DMA transfers but it is the firmware developer's responsibility to ensure that such methods are suitable, whereby a few things must be considered in the decisions:
1: There can be differences between devices in the same family whereby a peripheral may be a subset of the other and thus have some additional holes. For compatibility across devices this will needs to be respected
2: Not all instances of the same peripheral have the exact same registers - in some cases there may be a global control register in just one, or the number of FIFO registers change. Again, for compatibility, all possible instances need to be considered. [A method may be fine one one of the instances but then fail when applied to another].
3: Some peripheral registers require certain access types to operate correctly (eg. some NEED long word access and will ignore byte access) and so the standard memcpy() may not be suitable (but won't fail in the catastrophic manner) and different versions of memcpy() copying short and long words may be needed)

4: Some peripherals may be of a different endian-ness to the processor (eg. there are some big-endian peripherals around which have been inherited from older Freescale parts [eg. Watchdog in KE/KEA parts] but may have a flag that allows some parts to be set to little-endian - eg. the Ethernet controller.]). Some little to big endian swapping may also be needed when copying to registers in such cases.

5: When configuring peripherals it is often necessary to perform the configuration in a certain order (and sometimes write to the same register more that once). This means that actual configuration using a block copy may often be unsuitable.

Regards

Mark

[xxxajk]

1: There can be differences between devices in the same family whereby a peripheral may be a subset of the other and thus have some additional holes. For compatibility across devices this will needs to be respected

2: Not all instances of the same peripheral have the exact same registers - in some cases there may be a global control register in just one, or the number of FIFO registers change. Again, for compatibility, all possible instances need to be considered. [A method may be fine one one of the instances but then fail when applied to another].

3: Some peripheral registers require certain access types to operate correctly (eg. some NEED long word access and will ignore byte access) and so the standard memcpy() may not be suitable (but won't fail in the catastrophic manner) and different versions of memcpy() copying short and long words may be needed)

4: Some peripherals may be of a different endian-ness to the processor (eg. there are some big-endian peripherals around which have been inherited from older Freescale parts [eg. Watchdog in KE/KEA parts] but may have a flag that allows some parts to be set to little-endian - eg. the Ethernet controller.]). Some little to big endian swapping may also be needed when copying to registers in such cases.

5: When configuring peripherals it is often necessary to perform the configuration in a certain order (and sometimes write to the same register more that once). This means that actual configuration using a block copy may often be unsuitable.

While the code written by the original Freescale team is nifty and all, it isn't exactly easy to follow. Worse it doesn't target specific optimizations that are possible when possible. It also contains additional bloat sometimes that one needs to read through and dismiss mentally.

I optimize for common peripheral register sets, not for common families, and per CPU type where needed; CoretexM4 v.s. M0 for example.

This gets me the fastest and smallest code across all platforms that is readable and easy to manage with a common API.

I don't care about RTOS type junk either, as I have my own way of doing things that need to run in the background. It is called using an interrupt to its full potential. ;-)

[xxxajk]

First, I think I have found the issue.

Apparently you can't read the address holes within a peripheral. I'll be testing this shortly.

I'm using NetBeans with my own set of libraries and tool chain, because I find most other IDE a bit unintuitive.I also find that most provided libraries are lacking clarity and/or features that fit my customer needs. The only thing I did not write is the libc/libm, for that I use a modified and heavily tuned newlib. Writing hardware drivers, protocol stacks, etc are something that I find easy to do.

[xxxajk]

I have the SDK, etc but can't use it for the product due to customer's request that everything is done in-house.

Also, unfortunately, the demo isn't for this chip.

I did try to port the demo without success to the MKE16, but it will not compile without major fixes.

Perhaps I did not do it correctly, and will have to try again.

It would be helpful if there were demos for the MKE16.

There is no way that is obvious to import the demo when a board does not exist.

I will try again. Meanwhile, if possible, can you point me to a demo that will import?