Limitations of working with SDK?

[brunopaillard]

Hi

I recently upgraded to KDS 3.0 with SDK 1.2.0

I notice the following problems/limitations when I create projects with the SDK support. I am wondering if this is normal:

- I am trying to link all the code and interrupts at address 0x40000. My boot process already includes a resident bootloader at address 0x00000. That bootloader transfers control to code and interrupts at address 0x40000. However, when creating code using the SDK, the interrupt section always seems to be linked at address 0x00000, event though it is defined in Processor Expert to be linked at address 0x40000. Is that normal? Can that behavior be overcome?

- When working with the SDK it does not seem possible to do away with the UART debugger. Is that normal?

- When working with the SDK it does not seem possible to use the USB_LDD driver that is part of the Kinetis library. Is that normal?

Thanks

Bruno

[Jorge_Gonzalez]

Hello Bruno:

Here is some information regarding your questions:

1- If using Processor Expert you can change the memory segments from the CPU properties -> Build Options -> Generate Linker file. Picture below is for a K64FN1M0 target with the 0x40000 offset:

2- What do you mean with UART debugger? Do you mean the fsl_debug_console? If using MQX you cannot remove it but you could simply disable the pins as explained at the end of this thread:

What is the proper UART assignment for using printf with JTAG?

3- The USB_LDD is a legacy Processor Expert component not compatible with the KSDK USB libraries. Instead you should use the fsl_usb_framework component. In the next thread I shared an example project for K64 using this component:

Re: Standalone bare metal USB MSD with K64F, KSDK-1.1.0 and KDS 2.0.0, SDHC and fatfs

I hope this helps clarifying.

Regards!,
Jorge Gonzalez

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

[brunopaillard]

Hi Jorge

Sorry for the delay, I was traveling last week.

OK for all your answers, except the first one. I already configured the memory segments properly (see picture below)

Nevertheless there is an interrupt section created and loaded at address 0x000000 in the .elf file.

I am suspecting that the tools assume that the CPU is cold booting and that something must be at address 0x0 at least for long enough to allow a copy of the interrupt section that I assigned at the correct address (0x40000)... But I am far from sure, and in any case I am not in a cold boot situation, so if that is the problem, how can I do to bypass that?

Thanks

Bruno

[Jorge_Gonzalez]

Hi Bruno:

With those settings from the CPU there should be no code located at address 0x0. But I made some tests and this may be the flash configuration area that is causing problems. From your project please navigate to SDK -> platform -> devices -> [DEVICE] -> startup -> startup_[DEVICE].S. You will find a flash configuration section, something like this:

Delete it or comment it all and clean -> rebuild the project. Let me know if this gets better results.

Regards!,
Jorge Gonzalez

[brunopaillard]

Hi Jorge

Indeed that seems to be the section that causes the problem. When I comment that part, there is nothing at address 0x0000 anymore.

This being said I do not fully understand why (maybe you can explain):

The linker file includes (forces) a m_Flash_Config section, but it is at address 0x00000400, as it should be. Why is it then that decommenting that code creates a section at address 0x0000, which by the way looks very much like an interrupt section, rather than a Flash_Config section.

Bruno

[Jorge_Gonzalez]

Hi Bruno:

This is the behavior I see (considering the above memory offsets):

A) m_flash_config section in linker file + Flash configuration defined in startup file: The flash configuration is placed at 0x0400.

B) m_flash_config section removed + Flash configuration defined: The flash configuration is placed at address 0x0000.

C) Flash configuration commented out in startup file disregarding of linker file: No flash configuration in the binary/elf.

You should go with (C), but if you require a special flash configuration make sure to define it in the bootloader project.

I guess PE forces the m_flash_config section precisely to avoid case (B), but if you comment out the flash configuration then the linker does not find anything to place in that memory segment.

Regards!,
Jorge Gonzalez

[brunopaillard]

Hi Jorge

Then that is not it...

I am in case A): (There is a .FlashConfig section defined in the linker file, and it is located in the m_flash_config memory section that is also defined in the linker file. And there is a Flash configuration file defined in the startup file.

What I am seeing is a "contiguous" output section that starts at 0x00000000 and ends at 0x00000410. It INCLUDES the 16 bytes of Flash config from 0x00000400 to 0x00000410, but it also includes 1024 bytes of what looks strangely like an interrupt section...

When I remove the Flash config section from the startup file as you recommended, ALL of that disappears (the interrupt part from 0x00000000 to 0x00000400 and the Flash config part from 0x00000400 to 0x00000410).

!!!???

Bruno