K20 BSP Library Issue

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

K20 BSP Library Issue

2,078 Views
Vagni
Contributor IV

I started developing my first Touch Sensing application on my Kinetis K20-based (K20DN128VLH5) custom board with CW 10.2, MQX 3.8.1 and TSS 3.0.

I updated CW 10.2 with all the current updates and service packs; Processor Expert version is 5.3.

Because I want to use MQX RTOS, I first started to make the PSP and BSP libraries needed by my application, cloning the bsp_twrk20d50m psp_twrk20d50m libraries that come with MQX 3.8.1. I want to use Processor Expert LDDs to have the low-level drivers for my board.

 

On my board I use the same 8MHz crystal oscillator used on the TWR-K20D50M, but the RTC oscillator is not used (a 32,768kHz crystal is not mounted).

I set the CPU component for that configuration (48MHz clock for the cpu core, see the my attached ProcessorExpert.pe project file).

Then I got PSP and BSP libraries compiled and I wrote a simple "Hallo World" application to test them.

 

Starting the debugger, I get immediately a crash before the jump to my Main_task() function. I can see the cpu hangs executing the __pe_initialize_hardware() function in the generated Cpu.c file.

Executing step-by-step the code, I see the crash occurs when BSP initializes the hardware, after the enabling of the external oscillator and during the switching to FBE mode; the switch to PBE mode is never reached.

 

I haven't got a TWR-K20D50M for a reference. I can only see the 8MHz crystal oscillator is properly running on my board.

Could you please help me to solve this K20 BSP issue?

 

Another question:

The K20 cpu provides a USB controller. Driving the internal PLL to 96MHz it should be possible to have the 48MHz clock needed by the USB controller. Why in the K20 CPU component the USB clock settings are not present under the PLL/FLL clock selection property in the defined Clock configurations?

Because my application will use USB communication port, how can I be sure the 48MHz clock is properly provided by the clock configuration used?

 

Best Regards.

 

 

 

Original Attachment has been moved to: ProcessorExpert.pe.zip

Labels (1)
0 Kudos
Reply
4 Replies

1,481 Views
vfilip
NXP Employee
NXP Employee

Hello,

regarding the first post. You have to use the USB initialization component or USB_LDD to set the appropriate clock. For more details please see the attachment, I have extended you project of Init_USB component.

Regarding the second post. Do you have a project to reproduce the behavior?

best regards

Vojtech Filip

Processor Expert Support Team


1,481 Views
Vagni
Contributor IV

Hello Filip,

After some tests I realized my first board was damaged.

Then I got another board, similar to the first one, but with a new PK20DX256VLH7 device, which is different from the first K20 device.

So I cloned both bsp_twrk20d72m and psp_twrk20d72m libraries that come with MQX 3.8.1.

With Processor Expert I set only the CPU component for a 48MHz core clock configuration from the 8MHz external crystal and I had my new PSP and BSP libraries built.

Then I create a new MQX project with only a simple main() function, based on the twrk20d72m template and I modified it to use my new BSP and PSP libraries and built it.

The first time I lounched the Internal_Flash_Debug configuration I got a message saying "Device is secure. Erase to unsecure?". This was very strange, because the device mounted on my board was a new one. However, I confirmed the device erasing.

The debugger initial procedure always terminates with the message "No source available for 0x200F246".

If I hit the Resume command to the debugger, my main() function is never reached.

If I suspend the execution and hit a Reset command to the debugger, the system seems to reset but keeps running: I can see the device is waiting for an interrupt in the dispatch.s source file.

So I cannot develop my application with the K20 devices on my custom board.

I attach some screen-shot of CodeWarrior window and my projects.

Can you see where I am wrong?

Best Regards

0 Kudos
Reply

1,481 Views
Vagni
Contributor IV

I found the crash occurs when executing the following instruction in the __pe_initialize_hardware() function in the generated Cpu.c file:

/* MCG_C1: CLKS=2,FRDIV=3,IREFS=0,IRCLKEN=0,IREFSTEN=0 */

MCG_C1 = (uint8_t)0x98U;                            

when switching to FBE Mode.

0 Kudos
Reply

1,481 Views
DustyStew
Contributor V

I have just tried bringing up a TWR-K20D50M, with the GPIO example, and it crashes in the exact same place.

I don't see an answer to this problem here.

0 Kudos
Reply