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
