LPC4357 IAP bootloader - working only with ULink Pro

[lpcware]

Content originally posted in LPCWare by TP on Thu Aug 14 02:24:21 MST 2014
I'm writing bootloader for LPC4357. Bootloader is located at address 0x1A000000 and application binary image resides in external SPIFI FLASH.

After MCU finishes copying image into internal FLASH at address 0x1A010000, jump command is executed and application starts. This is only true if I use Ulink Pro for code download and testing. If i use Flash Magic, bootloader hangs at first IAP write operation.

I'm using Keil MDK ARM 4.73. LPC4537 is running at 204 MHz. I'm not using RAM reserved for IAP operations. All IAP operations are completed successfully if I use Ulink Pro for download & run.

If I don't use IAP commands, code is working fine, regardless of programming tool used.I don't have any special code inside UlinkPro INI script, just issuing reset. I've tried adding equivalent code inside SystemInit() function but there is no difference in code behavior.

Is there any special requirement before using IAP on LPC43xx platform?
I've build bootloader for LPC1768 platform and everything works as it should. I don't have ULink Pro on that board.

uint32_t write_data (uint32_t cclk, uint32_t flash_address, uint32_t *flash_data_buf, uint32_t count)
{
   uint32_t i, ret, interrupts;

   disable_interrupts(interrupts);

   for (i = USER_START_SECTOR; i <= MAX_USER_SECTOR; i++)
   {
      if (flash_address < sector_end_map)
      {
         if (flash_address == sector_start_map)
         {
            if ((ret = prepare_sector(i,i,cclk)) != 0)
            {
               printf("prepare for erase failed (%d)\n", ret);
               while(1);
            }

            WaitUs(1000 * 250); // not needed

            if ((ret = erase_sector(i,i,cclk)) != 0)
            {
               printf("erase sector failed (%d)\n", ret);
               while(1);
            }
         }

         if ((ret = prepare_sector(i,i,cclk)) != 0)
         {
            printf("prepare for write failed (%d)\n", ret);
            while(1);
         }
         break;
      }
   }

   param_table[0] = COPY_RAM_TO_FLASH;
   param_table[1] = flash_address;
   param_table[2] = (uint32_t) flash_data_buf;
   param_table[3] = count;
   param_table[4] = cclk;

   iap_entry(param_table,result_table);

   enable_interrupts(interrupts);

   return result_table[0];
}

uint32_t erase_sector (uint32_t start_sector,uint32_t end_sector,uint32_t cclk)
{
   param_table[0] = ERASE_SECTOR;
   param_table[1] = start_sector;
   param_table[2] = end_sector;
   param_table[3] = cclk;
   param_table[4] = FLASH_BANK;
   iap_entry(param_table,result_table);

   return result_table[0];
}

uint32_t prepare_sector (uint32_t start_sector,uint32_t end_sector,uint32_t cclk)
{
   disable_interrupts(0);

   param_table[0] = PREPARE_SECTOR_FOR_WRITE;
   param_table[1] = start_sector;
   param_table[2] = end_sector;
   param_table[3] = FLASH_BANK;
   iap_entry(param_table,result_table);

   enable_interrupts(0);

   return result_table[0];
}

// UlinkPro INI script

FUNC void Setup (void)
{
  // Reset peripherals: LCD, USB0, USB1, DMA, SDIO, ETHERNET
  _WDWORD(0x40053100, 0x005F0000);   // Issue reset
  _sleep_(1);
}

Setup();                             // Setup for Running

[lpcware]

Content originally posted in LPCWare by TP on Fri Aug 15 14:47:45 MST 2014
Thank you Sacha,
that was exactly what I needed.

[lpcware]

Content originally posted in LPCWare by daysacha on Thu Aug 14 10:11:10 MST 2014
You need to issue the IAP initialisation command before doing anything with the LPC43xx flash. It seems that a lot of the newer devices do not need it though, so NXP left this out of their example code. See the user manual and this bug report... LPC43xx and LPC18xx Flash programming functions incomplete

The ULINK uses IAP so will have issued this command for you. Flashmagic uses ISP so will not have(probably). This may be why it only works after programming with the ULINK. I'm guessing that once it is issued the flash remains 'prepared' until the device is reset. Don't rely on this though.

I hope this helps.

Sacha.

[lpcware]

Content originally posted in LPCWare by otscherw on Thu Aug 14 08:01:11 MST 2014
Hi,

Just a guess: as far as I know the COPY_RAM_TO_FLASH call expects that the data buffer (here flash_data_buf) is located in internal RAM. If this is not the case, you have to copy the data chuck to internal RAM before.

Oliver