Kinetis and Coldfire in a single Processor Expert project

[scottm]

I'm not convinced this is a great idea, but it seems like it should at least be possible.  I'm trying to create a project for a device that has both a ColdFire version and a new Kinetis version, and I'm trying to stick with Processor Expert whenever I can.  The manual implies that it can be done but I'm having a little trouble.  I'm using CodeWarrior 10.6.

I've got a Kinetis build configuration and a ColdFire configuration.  Each of them builds successfully, but switching presents problems.  The first is peripheral names.  The project has an async serial component, AS1.  On Kinetis it needs to be connected to UART0 and on ColdFire it's SCI1.  The manual says in section 3.2.2.1 that on-chip peripheral names can be changed to avoid this problem.  I don't see how to do that.  TX and RX pins would also have to be assigned new names.

The fix for that, at least for now, was to create a different AS1 component in each build configuration.  That part is working fine.

Now, the main problem is that there doesn't seem to be a way to change the generated code directory for each build configuration.  This is a problem because the Kinetis PDD files get deleted by PE when the CF configuration is built, and they don't get created again when the Kinetis target is built.  If PE is set to not delete unused files, the Kinetis component files cause problems for the CF build.  I can exclude them from that configuration and for the moment it's working, but it does prompt to create and delete some static files whenever the target is changed.

The fact that it's not switching cleanly makes me think that I'm not doing this right, if indeed it's supposed to work at all.  I'm afraid I'm going to cause myself trouble down the line if I don't figure out how to do this properly before I start complicating the project.

The alternative is to create two separate projects, keep the application code separate, and link the files in to both projects.  It certainly seems simpler, but if I can keep it in a single project without writing a bunch of ad hoc build scripts to fix the static files I'd like to do that.

Thanks,

Scott

[scottm]

I just wanted to add some further follow-up to this.  The project that was split between MCF51JM128 and MK22FN1M0 now has an MK22DX256 version as well.  I figured the two MK22 versions would be close enough that I could get by with two configurations of the same project, but it turned out to be still not worth the headache.  PE's code generation just doesn't handle it cleanly - all of the components have to be duplicated if they're not exactly the same and PDD file generation isn't handled well.  I split the MK22DX256 version off into a third project, again with the common code linked, and it works fine.

PE did its job in the sense that migrating to the new Kinetis part took maybe an hour.  It's great for migrating from one part to another, but not much good at maintaining parallel versions in a single project.

Scott

[trytohelp]

Hello Scott,

Just see Erich answered your question.

I worked on it too and attached an example using common file shared in 2 projects.

You've created a project using Processor Expert (PEx) with  the Project wizard for a specific device Coldfire.

After that you added a new device via processor Expert for Kinetis.

The system allows that but it will open lot of new problems.

The key problems are not linked to PEx only but more on the general project configuration.

In this case the project was created for Coldfire processor so using Coldfire Build tool chain and using specific Coldfire file as startup files and other libraries definition.

Mixing 2 architectures in the same project is definitely not a good option for me.

This configuration is working fine if you want to change the device (MK20 to MK10 for instance) but not for new architecture.

I don't see advantage to use it.

It's better to have a dedicated project for each architecture.

Now you can have common source files which are used in 2 projects.

Attached you will find an example using this feature.

I've created 2 projects  (MCF52259 and Kinetis) and a common files used by these project: fibo.c.

When I added the file I select the Link Project option.

Then a path file was added to the project.

If you modify the file, it will impact the 2 projects.

For Kinetis ...

Last year a new dedicated development tool for Kinetis was launched: Kinetis Development Studio (KDS).

This tool is Free of Charge.

For details please have a look to Kinetis Design Studio Integrated Development |Freescale

Have a great day,
Pascal
Freescale Technical Support
-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

[scottm]

Hi Pascal,

Yes, I encountered that problem with the build configuration.  I created the project for Kinetis and found that it was difficult to add my non-PE Coldfire project that had been migrated from CW 6.3, so I started over by creating a new PE Coldfire project.  I then imported the Coldfire configuration into a new build configuration in the Kinetis project, and that got the tool chain set up correctly.  I also had to duplicate the run/debug configuration (I use a P&E Cyclone Pro for Coldfire but haven't shelled out the $1200 for a Cyclone Universal yet so I'm using a Multilink Universal for Kinetis) and copy over the startup code and debugger memory configuration.

So yeah, it works, but the MCF51JM128's driver coverage in PE isn't on par with the MK22FN1M0's and like Erich said, it really works best in a serial sort of way when you're occasionally switching configurations and not trying to maintain them in parallel.

I like having shared code kept in a central repository outside of Eclipse's workspace anyway, so I think linking all of the application code in to each project will be the way to go.

Thanks,

Scott

[BlackNight · Accepted solution]

Hi Scott,

I'm doing something similar with many projects which I need to keep the 'same' for S08, ColdFire and Kinetis. What worked best for me is to have a project for each, and sharing the sources in a common folder. I only have the main.c, event.c and event.h common, everything else is in the 'common' part.

To keep things common on the component side, I have named the components the same way, using the same module prefix if possible (e.g. AS1_).

In cases where this does not work, I have created 'wrapper' modules and components to keep things the same.

Having multiple configurations works only if switching in a 'static' way for me: means having a project built for something, then keeping it in a configuration so I can go back, but the main development will be goin on with the new configuration.

I hope this helps,

Erich

[scottm]

Hey Erich, I just realized who you are.  I came across your blog when I started working on this stuff and it's had several useful tidbits so far.  I'm going to have to set aside some time to read it in detail.  Thanks for posting all of that!

Something I didn't see in your walk through or the demo included with the Freescale USB Stack 4.1.1 - my project got created with at least the AXBS settings and maybe the MPU settings such that the USB controller apparently couldn't get DMA access to the BDT.  I fixed the AXBS and had the MPU set to 'disabled' but I must have set the configuration to disabled (not sure if it was that way to start with or if I did that) so it still didn't work.  Took me many hours of digging into the protocol stack before I realized what was going on.  Noob mistake and I got to learn a lot about PE and the USB controller along the way, but it might be good to have that called out in the documentation!

Scott

[BlackNight]

HI Scott,

hmm, I had similar issues on Kinetis with MMU settings. Somehow the USB controller behaves really strange if some memory areas are not accessible. I have not used ColdFire and S08 for a while (moved my projects all to ARM with the exception of some legacy maintenance projects), but I don't remember that I have seen something like this with the ColdFire 52259 and JM devices.

Erich

[scottm]

Yeah, the symptom was that everything initialized fine but enumeration never completed.  As best I can tell, what happens is that the SIE gets set up properly and generates reset and SOF interrupts, and SOF packets are received just fine because the frame number is placed in a dedicated register, but it's unable to read the buffer descriptor so it doesn't know that endpoint 0 is enabled and ready to receive setup packets, so it never generates an ACK for the host's setup transaction and never generates a tok_dne interrupt.  It also does not seem to generate a DMA error interrupt, but presumably it gives an MMU access error.

The MCF51JM128 doesn't have the MMU so it was never a concern there.  This was only on the MK22FN1M0 that I was having the problem.  The MSD example I was going by in the USB stack documentation didn't cover it in the required PE settings either.

Scott

[BlackNight]

Hi Scott,

I faced the MMU problem with the FRDM-K64F: USB CDC with the FRDM-K64F, finally! | MCU on Eclipse

Erich

[scottm]

7 months, ouch!  Suddenly I feel a little better about wasting two solid days on the problem.  If I'd known about your blog earlier I'd have read the whole thing. Part of the problem with having so many part numbers and families is that solutions like this just don't ever show up in searches.  I think I'm going to read your whole blog now, before I do any more work on Kinetis.

Thanks,

Scott

[scottm]

That's exactly what I'd decided to do, unless someone presented a brilliant way to do this in one project.  I've maintained parallel HCS08 and Coldfire projects in CodeWarrior 6.2 before and I've generally kept good portability and modularity habits.  The MCF51JM128 doesn't seem to have a USB LDD component anyway, and I think it's going to be missing some others, so a wrapper layer is definitely going to be needed.

Fortunately at this point I'm not maintaining two related products with different capabilities, like the HCS08/Coldfire one.  The Kinetis board will quietly roll out in place of the Coldfire board.  Thankfully I planned ahead and the CF board's bootloader can take a multi-target firmware update file and just extract the part intended for it.  I can package the firmware updates together and the users won't need to know what hardware version they have.

The last week has been a crash course in CW 10, Eclipse, and PE, but I think I'm past the worst of the learning curve.  After 13 years on 'classic' CodeWarrior I suppose it's about time to learn something new.

Thanks,

Scott

[BlackNight]

Hi Scott,

yes, ColdFire does not offer the LDD components, they have been introduced with the Kinetis devices. That's why I have created portability layers between the 'classic' components the LDD components (see "There is a Time and Date for both Worlds | MCU on Eclipse "). As for the USB: you might consider the FSL_USB_Stack component which I created as a wrapper around the Freescale USB v4.1.1 stack. That stack has been replaced with the one in the Kinetis SDK (for Kinetis devices). I'm using that v4.1.1 stack devices sucessfully (with the same API) for S08, ColdFire (V1 and V2) and Kinetis. It only supports a few classes (MSD, CDC and HID), but that worked very well for me.

In case that would be something for you, I have several JM CodeWarrior projects posted here:

mcuoneclipse/Examples/CodeWarrior/DEMOJM at master · GitHub

I hope this helps,

Erich

[scottm]

Thanks, I saw that earlier and I plan to check it out.  I've been using an older version of the stack for CDC and MSD on the JM128 for years without trouble.  I got pretty familiar with the stack when I wrote a CDC bootloader for the JM128 that had to update itself in place - I had to set it up to maintain the connection state and resume execution at the proper place in the updated firmware when the stack itself was updated.  It was ugly and I hope to never do that again.  :smileywink:

I'll switch to KDS and KSDK when I absolutely have to.  I'm hoping I can hold out long enough on CW 10.6 that KDS and KSDK will have matured a bit by then.  I appreciate all of your work on the legacy stuff!

Thanks,

Scott