2011-12-07 01:48 PM
Okay, I've learned how to move code to Bank1, and it executes properly.
After having some problems getting bank1 booting to work, we decided to instead try copying our firmware into an external Flash chip and validate it, then switch to code which is entirely in Bank1, to write from the external flash back into bank0. I first wrote and tested code to enable unused sectors in Bank1 and write/verify code; this works fine. Now I'm trying to write code from Ext Flash to bank0: //************************************************************************************************** u8 *src = (u8 *) ALT_FEPROM ; u8 *dest = (u8 *) (0) ; // Bank0 Sector 0 bytes_remaining = datum[0] ; unsigned flags = disable_IRQ(); // make sure nothing tries to execute from bank0 !! set_led_green_on() ; while (LOOP_FOREVER) { wlen = (bytes_remaining > SIZE_64K) ? SIZE_64K : bytes_remaining ; // this function is executing successfully... if (feprom_program_enable_bank0(dest, BANK0_FM) == FALSE) { break; } set_led_red_on() ; delay_250msec(4) ; u32 u32SectorAddr; // if the physical address does not belong to any of the internal flash sectors, fail. if (!bank0_bGetBankSecAddrByPhyAddr((uint) dest, &u32SectorAddr, NULL)) { break; } // 12/07/11 - here is the show-stopper... // If I call this function, which writes to two registers in the internal flash-programming interface, // the sector erase proceeds successfully, but the code never returns to here... bank0_EraseSector(u32SectorAddr); // Erase the sector //************************************************************************************************** However, as the comments reflect, the sector-erase function never returns. I used OpenOCD via the JTAG interface, to look at bank0 space after the crash, and it appears that the erase *did* occur, but the function never returns. bank0_EraseSector() contains only two writes to the STR9 CUI interface: //************************************************************************************************** static void bank0_EraseSector(vu32 FMI_Sector) { /* Write an erase set-up command to the sector */ *(vu16 *)FMI_Sector = 0x20; /* Write an erase confirm command to the sector */ *(vu16 *)FMI_Sector = 0xD0; } //************************************************************************************************** So why does this crash? What else do I need to do to make this work? I tried remapping bank1 to boot bank and bank0 to non-boot bank, using // FMI_BankRemapConfig(0, 6, 0x80000, 0) ; // this crashes the board immediately!! but that doesn't work either... Our system: STR912 512K/32K2011-12-27 08:08 AM
Dear Sir, I have one problem with MCU STR912FA46; when code of program less then 512 kB, MCU is working well. But when code of program more then 512 kB, my program no working and MCU going on the PDAbort vector. Because program is good and I add only BMP-file for presentation. I am using Keil MDK 4.00. All setup for FMI is correct. Where are I can mistake? Best regards. Vladimir,
2012-05-07 03:21 AM
Hi...
I am also experiencing similar kind of problem as mentioned above. I am working on str912faw44, putting bootloader into bank1, through bootloader code i am programming bank 0 and running it after remapping. My problem is if bank0 code size is less than 8k, everything works fine, but if code size becomes more than 8k it doesn't get downloaded properly into bank0.2012-05-11 08:50 PM
a data abort usually indicates an invalid address. you might check the assembler code just before the abort for any such invalid address access.
2012-05-15 11:32 PM
Hi..
just want to be more specific for my problem. Through bootloader code I am writing main app code in FMI B0S0 starting from the memory location 0x80000 onwards. If code size is <0x2000 bytes no problem, but if size is greater than 0x2000 bytes(>8K) and when i try to write at 0x82000, something goes wrong. On debugging i got that when try to write to this location FMI_FLAG_PS (program failure) become set, because corresponding FMI_FLAG_SPS (sector protection) is also set, but sector write protection is disabled before start writing, thats why it could become possible to write upto 0x81fff. I couldn't understand whats happening, can that location corresponds to OTP, or something wrong with remapping. Please suggest.2012-05-17 06:17 AM
have you reviewed the errata sheet?
2012-05-19 02:44 AM
yea..i had gone through the errata sheet as well and tried for workaround for TCM order bit through assembly language, but still no help. Other conditions mentioned in sheet were not in accordance with my problem. Any other idea???
2012-05-20 11:26 PM
try to write at 0x82000 first?
2012-06-05 12:16 AM
2012-06-06 01:07 AM
just a clarification, in your original problem, it was related to size? so now it is really not a size issue, just that you cannot write 0x82000?