MQX 3.8.1.1 fopen() Bug on MPC-5125

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

MQX 3.8.1.1 fopen() Bug on MPC-5125

Jump to solution
794 Views
Tim562
Senior Contributor I

Hi All,

     I've run across what I believe might be an MQX bug (MQX 3.8.1.1 - MPC-5125) in the fopen() function and I'm curious if anyone else may have seen anything similar.

As per the MQX bootloader example code I'm calling fopen() to obtain a file handle for the flash device on the TWR-MPC-5125 so I can read the firmware image table like this:

_mqx_int ReadImageinfo(void)      {      MQX_FILE_PTR flash_hdl = NULL;      uchar_ptr  read_buffer = NULL;      IMAGE_INFO_PTR image = NULL;

     //Make sure we can access our flash      //----------------------------------------------------------------------------      flash_hdl = fopen(FLASH_NAME_INIT, NULL);   //<-This line corrupts the processor STD_PU register from 0x4B to 0x23      if(flash_hdl == NULL)           return(0);

//Allocate a read buffer and read in the image table info //----------------------------------------------------------------------------      read_buffer = (uchar_ptr)allocate_buffer(IMAGE_TABLE_SIZE*NAND_FLASH_PAGE_SIZE, "read");      if(read_buffer == NULL)           {           fclose(flash_hdl);           return(0);           }      else           image = (IMAGE_INFO_PTR)read_buffer;

     fseek(flash_hdl, IMAGE_TABLE_LOCATION, IO_SEEK_SET);      read(flash_hdl, read_buffer, IMAGE_TABLE_SIZE);      fclose(flash_hdl);

     return(0);

     }

      As soon as I call "flash_hdl = fopen(FLASH_NAME_INIT, NULL);" (line 10 above) a processor configuration register that stores the configuration for the LocalPlus Bus CS_1 pin is changed from my set value of 0x4B to 0x23. This register is located at IMMRBAR_BASE + 0x0000A008 (register is STD_PU at 20.2.2.3.1 in MPC5125 Microcontroller Reference Manual, Rev. 2 11/2009) and is responsible for selecting which alternate function the port pin shall perform. The value I set it for at boot time (0x4B) configures it as CS_1 in support of the LocalPlus Bus. The value it changes to is a reserved value not defined in the manual. And obviously once it changes I loose the ability to communicate with the device on the LocalPlus Bus that was using CS_1.

     If I re-write the 0x4B value to this register after calling fclose() then operation of CS_1 on the LocalPlus bus is restored. I'm not sure what else this could be but an MQX bug? Does anybody have any other suggestions or have you seen anything similar? I'm currently using MQX 3.8.1.1 with the RTCS code upgraded to the 4.0.2 revision and Code Warrior 9.2. Thanks!

~Tim

Tags (2)
0 Kudos
Reply
1 Solution
525 Views
Tim562
Senior Contributor I

Sorry, false alarm. This is NOT an MQX problem. It turns out that the LocalPlus Bus CS_1 pin I was using is also used as a nand flash CS signal on the TWR-MPC-5125 board. So when you open the flash device, MQX ensures that all IO pins that will be used to communicate with the flash are properly configured to do so. In case anyone is wondering, the MQX function "bsp_nandflash_io_init()"  (in mqx\source\bsp\twrmpc5125\gpio_init.c ) is doing this task. Sorry..

~Tim

View solution in original post

0 Kudos
Reply
1 Reply
526 Views
Tim562
Senior Contributor I

Sorry, false alarm. This is NOT an MQX problem. It turns out that the LocalPlus Bus CS_1 pin I was using is also used as a nand flash CS signal on the TWR-MPC-5125 board. So when you open the flash device, MQX ensures that all IO pins that will be used to communicate with the flash are properly configured to do so. In case anyone is wondering, the MQX function "bsp_nandflash_io_init()"  (in mqx\source\bsp\twrmpc5125\gpio_init.c ) is doing this task. Sorry..

~Tim

0 Kudos
Reply