Anyone ported to a 52255?

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

Anyone ported to a 52255?

1,609 Views
dhlocker
Contributor III

I'm putting  MQX (I'm using 3.5.1 with CW7.2) on a special purpose board, driven by a 52255.

 

The biggest difference, of course, is the lack of the MiniFlexBus, so all the MRAM references have to go.  Ditto any manipulations of the FB pins in their Secondary, Tertiary or Quatenary identities (PAS2, and PTE[], PTF[], PTG[], PTH[]

 

  I've modified the .lcf, .mem, and .cfg files to make MRAM non-existent, but is there a simple way to disable the pin configuration code?  (Ideally, I'd like to

 

#define MQX_CPU                 PSP_CPU_MCF52255

 

but then I'd have to define the characteristics of the 52255 and put in all the controls, which seem to be in io_gpio_mcf5225.c, but without distinguishing between the 52255 and the 52259

 

TIA for any suggestions,

Donald.

Tags (2)
0 Kudos
10 Replies

613 Views
trailman
Contributor V

I had the same problem when porting MQX 3.4 from MCF52259 (EVB board)  to a custom board with a MCF52254 (100pin without Flexbus).

 

Changing the CPU type dit not solve the problem. Iin fact 52259 and 52254 or 52255 are the same so you can build for any of them and it works.

 

I had to remove the following lines in mcf5225_init() in bsp_init.c (related to Flexbus) :

 

 

    /* Enable Mini FlexBUS signals (used by external MRAM and CPLD) */    reg_ptr->GPIO.PASPAR = 0x20;   /* enable CS1 operation for CPLD */    reg_ptr->GPIO.PTEPAR = 0xff;    reg_ptr->GPIO.PTFPAR = 0xff;    reg_ptr->GPIO.PTGPAR = 0xff;   /* enable CS0 operation for MRAM */    reg_ptr->GPIO.PTHPAR = 0x5555;        /* Enable external MRAM mapped on CS0 */    reg_ptr->FB.CSAR0 = 0x10000000; /* CS0 base address */    reg_ptr->FB.CSCR0 = 0x00000540; /* CS0 control (8bit data, 1 waitstate) */    reg_ptr->FB.CSMR0 = 0x00070001; /* CS0 address mask and enable */

 

 

 

0 Kudos

613 Views
trusc
Contributor II

Hi

 

What about the ALLPST output? The 52255 does not have the PST[3:0] outputs. In the bsp_init.c file the Program Status outputs are enabled by this line:

 

reg_ptr->GPIO.PDDPAR = MCF5225_GPIO_PDDPAR_PST;

 Should I leave this as is, or must I redefine MCF5225_GPIO_PDDPAR_PST? If so, where?

 

Thanks

0 Kudos

613 Views
trusc
Contributor II

Has anyone worked through AN4287 Rev. 0: "MQX Board Support Package
Porting Guide" ?

 

On p. 10, near the bottom of the page, item 4 reads: "Change the Output directory so that it points to [MQX INSTALLATION ]\lib\CUSTOM_BOARD_mcf52259.cw\mqx."

 

Shouldn't this read: "Change the Output directory so that it points to [MQX INSTALLATION ]\lib\CUSTOM_BOARD_mcf52259.cw\psp." ?


0 Kudos

613 Views
c0170
Senior Contributor III

Hi trusc,

 

you're right , there's should be psp directory not mqx.

 

Regards,

MartinK

0 Kudos

613 Views
trusc
Contributor II

Good! Thanks Martin.

0 Kudos

612 Views
Tonkabot
Contributor III
I have a mcf52255 100pin on my board, and I had no trouble at all running the 52259demo examples, my processor expert testing, and now my own 'bareboard' MQX project. The biggest trick was in learning how to set up the debugger properly, (CW10) and somewhere in in the debug configuration on the debugger tab there is a 'target processor' selection.
0 Kudos

613 Views
dhlocker
Contributor III
Thanks for the reply. I'm moving on; now most of my issues seem to be remapping the pins from the EVB assignments to whatever the local H/W people assigned the pins. I did manage to clone the evb and used a pile of sh scripts to change all relevant strings. Definitely getting CW10 flying straight was a bit of a challenge.
0 Kudos

613 Views
Tonkabot
Contributor III
I made very sure to examine the 52259EVB, 52259DEMO, and TWR52259 USB and make mine as Identical as I could. The virtual_com CDC demo worked perfectly the first time, it was heaven to hear the 'DingDong' of the USB attach from my PC. After the weeks of fighting with CW7.2 issues on my PC, and then trying to work with CW10 beta. Thank the Gods for the CW10 release, it could have saved me a couple weeks, but at least it is here. I also found that merging the processor expert code and MQX code to be tedious but not too bad - the big trick are the interrupts, which now that I have one working correctly (the DTIM1 timer clocking from an external source) I think the others will be easy. A problem I ran into there was that when I took the mqx\examples\isr\isr.c example, I found that I could NOT chain to the old_isr, as that caused the unhandled interrupt error and blocked that task.
0 Kudos

613 Views
Tonkabot
Contributor III
Ok, I realize now that the 'no trouble porting demos' was for taking a couple files from the demos and putting them in my 52255 project (on CW10). When I go debug any of the existing demos, I find that the debugger dies on loading, specifically at the point it tries to access Mini-FlexBus registers. They compile, but what I thought were download issues are actually trying to talk to FlexBus issues. So it is with much greater understanding that I read your initial post Don, and before coming back to this thread I actually tried exactly your desired define '#define MQX_CPU PSP_CPU_MCF52254' and of course that does not work. Now, I am looking for the .lcf , .mem, and .cfg files. they don't exist in my CW10 project, it is either using them from their locations in the lib area (I see MQX 3.6/lib/m52259demo.cw/mqx/dbg/m52259demo.mem, and the others) or CW10 does something completely different. Can you post your updated header file that you created with a script? Really thanks in advance! Brynn
0 Kudos

613 Views
dhlocker
Contributor III

The changes that I made with the scripts were not relevant to the CW10 files, but to the application I was generating.

 

The changes I made to make so CW would recognise the 52255 without thinking it was a 52259 were:

 

in user_config.h:
/* mandatory CPU identification */
/* PSP_CPU_MCF52255 is appropriate for this product,
 * with suitable changes to psp_cpudef.h (to actually define this macro) */
#define MQX_CPU                 PSP_CPU_MCF52255

 

in mqx/source/psp/coldfire/psp_cpudef.h
#define PSP_CPU_MCF52255            (PSP_CPU_NUM(PSP_CPU_ARCH_COLDFIRE, PSP_CPU_GROUP_MCF5225, 5))

 

Of course, after doing this, I discovered that no one actually uses either the PSP_CPU_... definition or the PSP_CPU_GET_VAR() macro.

 

The PSP_CPU_GET_GROUP() is used in a number of mqx/io source files, but I'm not using the io subsystem.  The only other file I've found that might need to be edited based on PSP_CPU_GET_VAR() is mcf5225.h; I haven't had to modify it yet  (I made all processor-specific changes in my bsp code and I'm just not using registers not present in the 52255)

 

HTH,

Donald.

0 Kudos