Author Topic: porting utasker to MCF5282 or other non supported targets  (Read 5907 times)

Offline s2c97

  • Newbie
  • *
  • Posts: 9
    • View Profile
porting utasker to MCF5282 or other non supported targets
« on: April 01, 2010, 10:08:40 PM »
Hi,

I'm in the middle of developing embedded software on the Freescale MCF5282 on our new product and I'm evaluating the option of porting utasker to our target processor.  I'm very interested at the utasker bootloader in particular.

I was wondering if any of you has already done a similar task (on the 5282 or other processors) and if he could kindly share some of his experiences and any technical pointers.

kind regards,
s2c97

Offline mark

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 3021
    • View Profile
    • uTasker
Re: porting utasker to MCF5282 or other non supported targets
« Reply #1 on: April 01, 2010, 11:10:30 PM »
Hi

I have to admit that the MCF5282 is the next closest to the supported devices due to the fact that it is a real single-chip device (with 64k RAM (+2k Cache) + 512k FLASH).

The Ethernet controller looks compatible, as are probably most peripherals.

This means that it may already run a simple test - like blinking LED, UART or maybe even ping (depending on the PHY used).

The first difference that is however obvious is that it uses a different FLASH technology. Rather than the 2k or 4k (Kirin3) Flash granularity that is known form the other devices, the granularity is 16k (32 x 16k sectors). This possibly means that the programming algorithm is a bit different but it certainly means that the use of the FLASH sometimes requires a different strategy:
1) The uParameterSystem (usually used to save IP settings and MAC address) may be wasteful of memory (it uses one or 2 sectors - when swap block is active. Possibly small parameter storage may even be better in an external EEPROM (?)
2) The large granularity is not so suitable for the uFileSystem since a file will occupy multiples of the flash granularity. In this case there is however the LARGE-GRANULARITY mode which is used by the NXP and STR91 project and described here: http://www.utasker.com/docs/STR91XF/FileSystemSTR91X.PDF


Keeping goals specifically fixed on a boot loader, it seems that the best method would be to configure the uTasker project as simple web server with build in default web page which allows firmware upload via HTTP post. This will require 2 x 16k sectors of internal FLASH but leaves the rest free for application code, The application code can be from a completely different project and, if there is large external memory, even ucLinux based, for example.

The boot needs to be able to detect whether there is a valid application loaded. If not (or if a defined port input is in a certain state [forced loading mode]) it can run the uTasker project code so that the application can be installed. If a valid application is detected (exactly how it detects it needs to be defined depending on exact requirements but could be as simple as checking that the code at 0x8000 has a valid SP value and a realistic PC value or even checking a check-sum of its image) it can simply jump to it as the bare-minimum boot loader, or the SREC UART loaders do.

To prepare for a new upload either the input forces the board to start in loader mode or the application can delete itself (or at least make itself invalid so that the boot loader is started - one other method used was also to reserve a magic number at a define location in RAM so that the boot loader recognises that the application is signaling that it should start after a reset).

The biggest jobs that I see are ensuring that the FLASH driver works correctly for the internal FLASH. If the application is large and needs to be also stored in external FLASH a corresponding second driver will need to be added to handle the programming and deletion in that area.

Another important detail with Ethernet based loaders is where the IP and MAC comes from. Often this is managed by the application but the boot loader may need to know where the information is to allow it to use the correct values. When no application and no settings a default set may be used (or DHCP) but usually at least the MAC should be unique...

Looking forward to some feedback from people who have actually used the chip together with the uTasker project ;-)

Regards

Mark


P.S. Although I don't have a board for this device I expect that it would be possible to get a good first show using the uTasker simulator .
P.P.S. Since these devices are only available in MAPBGA there are some restrictions due to patent issues and they don't seem to be available everywhere - I don't know whether EVBs can be obtained by everyone...(?)

Offline aersek

  • Newbie
  • *
  • Posts: 17
    • View Profile
Re: porting utasker to MCF5282 or other non supported targets
« Reply #2 on: April 03, 2010, 04:06:14 PM »
I'm using uTasker with MCF5282. Porting was not hard because I know from earlier very good this processor, about 3 days of work. Flash in MCF5282 is organized in 2kbyte blocks and all uTasker flash driver capabilities can be user withouth any problem, uParameterSystem and uFileSystem. I can acknowledge that flash driver operates correct without any modifications. Diferences between MCF52233, MCF52259 and MCF5282:
MCF5282 processor main specificity:
- has probably almost same FEC, UARTa, CAN, DMA timers, FLASH, SRAM, PIT, QSPI, I2C... interfaces as other ColdFire processors
- has internal 2kB cache
- has different ADC
- has different GPIO ports
- has 2 GPT timers
- has not PWM, PHY, USB, additional EdgePort
- has different power management system
- has full scale external bus interface with 7 chip-selects, 24bit address bus and 32bit data bus
- has SDRAM controller with 2 SDRAM chip selects
- has DMA controller memory map little bit different than DMA controller on MCF522XX but with almost same functionality; big disadvantage of DMA is bug in silicon because of which DMA can not be used for UART transmit directly; instead of that you need to use DMA timer with timeout period same to character send time to fire DMA controller on every character if you want DMA supported UART transmit.

To port uTasker to MCF5282 you need mainly change M5223X.h, M5223.c, app_hw_m5223x.h and config.h. You can use most of drivers withouth any changes, biggest digerence is in UART DMA, but you u can use UART in interrupt mode without any changes. In M5223X.h you need to add external bus interface registers, GPIO port registers, defin PLL frequencies, chang interrupt vector table, add PHY registers definition, add new DMA definitions, add second GPT, add SDRAM controller and defferent ADC, change interrupt vector table... Somewhere in early initialization code before any usage of uMemset, uMemcpy, uMalloc you should add this: MPARK = 0x33e100 to enable BCR24BIT and M2_P_EN.
For last few months I'm planing to send to Mark mine MCF5282 uTasker base reference project, but still I didnt, I'll send it during next week. I planed to finish it so it can be used by anybody as real reference project, but I newer finished it.

Best regards

Andrija Ersek

 

Offline jezc

  • Jr. Member
  • **
  • Posts: 62
    • View Profile
Re: porting utasker to MCF5282 or other non supported targets
« Reply #3 on: April 04, 2010, 08:31:07 PM »
Hi,

Could you also please indicate which development board for the 5282 you've got the port working on - or is it on custom hardware?

We have a Freescale 5282 EVB board as well as our own custom designs.

Also, as a more general point, is there a guide to porting to different processors and/or custom hardware designs? Sorry if I've missed something but I couldn't see anything under the documents section.

We're using a variety of processor types (Freescale, NXP, Atmel, ST for example) and are keen to use uTasker where appropriate.

Any advice/help will be most welcome!

Cheers,
    Jez

Offline aersek

  • Newbie
  • *
  • Posts: 17
    • View Profile
Re: porting utasker to MCF5282 or other non supported targets
« Reply #4 on: April 05, 2010, 12:03:24 PM »
I have 5282 EVB but on it I have made initial development tests of our software before usage of uTasker. I started using uTasker when I was working for half year on custom hardware and didn't work port on EVB. For all portings as I see you only need to change files in Hardware folder and some application files. If you port to similar processor (5282, 5329 ...) you need just to change bunch of definitions, some of initialization code and add some driver functions for unsupported parts of processor, but 90% of drivers will work without any change. Some porting tips you can get in this theme http://www.utasker.com/forum/index.php?topic=281.0.

Regards

Andrija Ersek

Offline s2c97

  • Newbie
  • *
  • Posts: 9
    • View Profile
Re: porting utasker to MCF5282 or other non supported targets
« Reply #5 on: April 05, 2010, 07:00:38 PM »
@aersek
This is really encouraging news to hear from a user that actually ported utasker to the MCF5282.  I really appreciate that you shared your experience and would love to see your base reference code of your version of utasker for the 5282.

I was a little bit concerned with the internal memory flash since it is superFlash technology but discovered (like you mentioned) that it can have a single erase page of 2k which is comparable granularity as the other supported devices.  I'm not to concerned about not being able to do DMA on UART since I will be using it differently.

So I am more confident now to go ahead and invest some time in utasker to port the code to our project and 5282 processor.

kind regards,
s2c97

Offline SVC1

  • Newbie
  • *
  • Posts: 2
    • View Profile
Re: porting utasker to MCF5282 or other non supported targets
« Reply #6 on: April 21, 2010, 09:35:33 PM »
Hi,

I just embarked in utasker and I intend to use it on 5282 as well.

My goal is the following:
- My own BootLoader that will copy the image file stored on a SPI-ROM (Flash or EEPROM) into SDRAM and jump to it to start the application.
- The uTaskerFileSystem will be another (rather big) spi ROM to store mainly HTML files.

Hope it is not too ambitious project…


>  For last few months I'm planning to send to Mark mine MCF5282 uTasker base
> reference project, but still I didn’t, I'll send it during next week.


Any progress on making the port available  ;)?

SVC



Offline mark

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 3021
    • View Profile
    • uTasker
Re: porting utasker to MCF5282 or other non supported targets
« Reply #7 on: April 21, 2010, 10:33:50 PM »
Hi

I have in the meantime received Andrija's reference and am also slowly becoming acquainted with the device (and its many ports). At the moment I don't actually have a development board so am looking around for such a thing - I understand that there are various problems due to a BGA patent issue (restricted to the USA) but European suppliers may be able to help.

The code has been partly integrated now and the simulator is also starting to work as an M5282. I will send you the low level change reference which may help you and suggest that any technical issues be discussed here - I have started to understand quite well the workings of this chip (apart from cache and the SDRAM interface) so may be able to offer some detailed advice too ;-)

Regards

Mark