Fabio,
What you did looks good.
Enabling KEYEN allows software to disable the protection. The software needs to be installed on the device before the protection is enabled. I imagined the scenario that someone implemented backdoor key access and then found, too late, that our default setting was to disable it. I felt that it was a no risk option to enable backdoor key access by default as it does nothing without suitable code already installed on the device.
It was a very secondary consideration and I can confirm you did no wrong!
Derek
Kinetis support in trunk
Moderator: utzig
-
- Posts: 49
- Joined: Mon Aug 11, 2014 6:40 am
Re: Kinetis support in trunk
Minor patch to declare _pal_lld_setpadmode() in pal_lld.h
- Attachments
-
- 0001-KINETIS-Add-declaration-for-_pal_lld_setpadmode.patch.gz
- (501 Bytes) Downloaded 256 times
-
- Posts: 49
- Joined: Mon Aug 11, 2014 6:40 am
Re: Kinetis support in trunk
Patches to add/correct register definitions and fields for DMA, DMAMUX, PIT and FTM0 for the mk20d50m chips.
- Attachments
-
- 0001-KINETIS-FTM-registers-and-fields-removed-TPM.patch.gz
- (3.87 KiB) Downloaded 261 times
-
- 0001-KINETIS-PIT-registers-and-fields.patch.gz
- (1 KiB) Downloaded 261 times
-
- 0001-KINETIS-DMA-and-DMAMUX-registers-and-fields.patch.gz
- (5.36 KiB) Downloaded 264 times
-
- Posts: 49
- Joined: Mon Aug 11, 2014 6:40 am
-
- Posts: 359
- Joined: Sat Jan 07, 2012 6:22 pm
- Location: Brazil
- Has thanked: 1 time
- Been thanked: 20 times
- Contact:
Re: Kinetis support in trunk
Derek,
I applied the FTM changes but now reviewing it more carefully I would suggest changing
to
That would enable using the timer with code like:
The "C" would not conflict with any register and would be more succinct and map better to the naming in the RMs like FTM0_C0SC, FTM_C1V, etc. What do you think?
Regards,
Fabio Utzig
I applied the FTM changes but now reviewing it more carefully I would suggest changing
Code: Select all
struct FTM_Channel {
__IO uint32_t CnSC; /* Channel Status and Control */
__IO uint32_t CnV; /* Channel Value */
} CHANNEL[8];
to
Code: Select all
struct {
__IO uint32_t SC; /* Channel Status and Control */
__IO uint32_t V; /* Channel Value */
} C[8];
That would enable using the timer with code like:
Code: Select all
FTM0->C[0].SC = 0;
FTM1->C[1].V = 0,
etc
The "C" would not conflict with any register and would be more succinct and map better to the naming in the RMs like FTM0_C0SC, FTM_C1V, etc. What do you think?
Regards,
Fabio Utzig
-
- Posts: 49
- Joined: Mon Aug 11, 2014 6:40 am
Re: Kinetis support in trunk
Yes, I didn't like the word CHANNEL too BIG and SHOUTY
C aligns with the documents and looks better.
C aligns with the documents and looks better.
Re: Kinetis support in trunk
Found one typo in the mk20d5.h (path: os/ext/CMSIS/KINETIS), line 622
K20 Sub-family reference manual P.241 say it is field 1 for DMAMUX. Probably a mix up of binary notation and hex.
#define SIM_SCGC6_DMAMUX ((uint32_t)0x00000010) /*!< DMA Mux Clock Gate Control */
It should be:
#define SIM_SCGC6_DMAMUX ((uint32_t)0x00000002) /*!< DMA Mux Clock Gate Control */
K20 Sub-family reference manual P.241 say it is field 1 for DMAMUX. Probably a mix up of binary notation and hex.
#define SIM_SCGC6_DMAMUX ((uint32_t)0x00000010) /*!< DMA Mux Clock Gate Control */
It should be:
#define SIM_SCGC6_DMAMUX ((uint32_t)0x00000002) /*!< DMA Mux Clock Gate Control */
-
- Posts: 49
- Joined: Mon Aug 11, 2014 6:40 am
Who is online
Users browsing this forum: No registered users and 2 guests