NXP boards: nxp: frdm_ke16z: New board with 64kB Flash device added

[mgalda82]

boards: nxp: frdm_ke16z: New board with 64kB device added
Related to HAL_NXP: PR#595
zephyrproject-rtos/hal_nxp#595

SOC_MKE16z4 and MKE15z4 (64kB, 48MHz) is now supported by DT
LPFLL clock option with proper frequency select
dts: nxp_ke1xz64.dtsi added.
lpfll_clk node defined in specific dts files, because of different frequency support
Tested on board: frdm_ke16z with "hello_world" and "blinky"

Signed-off-by: Michael Galda [email protected]

[github-actions]

The following west manifest projects have changed revision in this Pull Request:

Name	Old Revision	New Revision	Diff
hal_nxp	zephyrproject-rtos/hal_nxp@7a52cbb	zephyrproject-rtos/hal_nxp#595	zephyrproject-rtos/hal_nxp#595/files

⛔ DNM label due to: 1 project with PR revision

Note: This message is automatically posted and updated by the Manifest GitHub Action.

[decsny]

depending on how similar all the KE boards are, you might want to consider combining them all into the same folder and sharing files. Because the amount of files to maintain is getting out of hand otherwise if they are mostly the same board but with a very slightly different chip

[mgalda82]

depending on how similar all the KE boards are, you might want to consider combining them all into the same folder and sharing files. Because the amount of files to maintain is getting out of hand otherwise if they are mostly the same board but with a very slightly different chip

Hi Declan, yes I see. It is oppositely, the KE devices are very similar and the FRDM boards contains similar peripherals, but routed to a different pins (due different packages, nobody cared about the pin compatibility). I believe it could be somehow combined, creating some overlays, etc.. But it would add even more mess.

[decsny]

depending on how similar all the KE boards are, you might want to consider combining them all into the same folder and sharing files. Because the amount of files to maintain is getting out of hand otherwise if they are mostly the same board but with a very slightly different chip

Hi Declan, yes I see. It is oppositely, the KE devices are very similar and the FRDM boards contains similar peripherals, but routed to a different pins (due different packages, nobody cared about the pin compatibility). I believe it could be somehow combined, creating some overlays, etc.. But it would add even more mess.

Do you know that multiple boards can be defined in the same folder at least? You can define as many boards in the board.yml as you want. If there is any reasonable similarity, I think they should go in same folder. But up to you. Same comment for MCXC and MCXA but I don't know who is responsible for those.

[dleach02]

@mgalda82 I updated your PR to address the west.yml conflict

Please address the compliance issues. From what I can see, you are mixing spaces with tabs at the beginning of lines. Just use tabs in most cases. In cases where you are trying to align a continuation line you can do the tabs to align with the line above then spaces to do any tweaks.

[mgalda82]

@mgalda82 I updated your PR to address the west.yml conflict

Please address the compliance issues. From what I can see, you are mixing spaces with tabs at the beginning of lines. Just use tabs in most cases. In cases where you are trying to align a continuation line you can do the tabs to align with the line above then spaces to do any tweaks.

Hi David, is there anything still wrong, or have you already fixed and updated it, please?
Sorry, but when switching between 5 job tasks, I will newer generate the hi-quality output.

[decsny]

waiting for answer about why new board folder is needed

[mgalda82]

waiting for answer about why new board folder is needed

Hi Declan, I understand your care.
Because it is a different board (boards subsequently added and tested in different time) and now I am too lazy to merge everything to one folder and test it again. Sorry for my ignorance.

[dleach02]

I'm fine with a board for this new FRDM board.

@mgalda82 I've updated your PR to address the west.yml changes needed, fix the compliance issue in soc.c, rebased to main and force pushed your branch. Now we wait on CI

[dleach02]

All is fine with the PR. We just need to clean up the compliance check problem (space) and address the documentation build. There was a recent repo-wide change made with the doc pages so I suspect you need to adjust your doc page to align.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
1.8% Duplication on New Code

See analysis details on SonarQube Cloud