NOR flasher hangs on ICE board

Vladimir,

ICEv2.1 has a limitation due to pinmux conflicts and can access only 512k directly. Inorder to access address space above 512k, a GPIO must be asserted. Please check the schematics here

The address lines A0-A17(Data upto 512k)are connected, along with two GPIOs - GPIO2_12 and GPIO2_13(A18 and A19)

The observation you see now when reading Sector 9 would be Sector 1 as the GPIO is not asserted.

A similar implementation is already present in the nor flasher, but it is for ICEv1 boards(ICEv1 had a limitation of 128k direct access). You can use this as a reference.

Regards,
Vinesh

Vinesh,

Thank you for fast reply.

I've tried to program GPIO ports like for ICEv1, but under debugger I can see that memory content was not changed ((0x080xxxxx) for different sectors.

Code changes I've added:

void main()
{
...
    GPIOInitialization(2);
...
    else if(boardType == AM335X_BOARD_TYPE_ICE_V2)
    {
        GPIOSetOutputPin(2,12);
        GPIOSetOutputPin(2,13);
    }
...

}

for NORFlashErase and NORFlashWrite I call the function:

void SetNORAddrGPIOPinForICE2(UINT32 address)
{
    UINT16 gpioPinVal = 0;

    gpioPinVal = 3& (((UINT16)(address >> 19)));

    GPIOEnableDisableOut(2,12, gpioPinVal & 0x01);
    GPIOEnableDisableOut(2,13,(gpioPinVal >> 1) & 0x01);
}

How can I verify that GPIO2_12 and GPIO2_13 was set correctly?

May be GPMCPinMuxConfNor does not set correct mux for the board? 

Where can I find which pin mux values should be used for this board?

Regards,

  Vladimir

Vinesh,

Thanks for help!

After changing pin mux mode to 8, I can see memory content was changed.

 "3&" is not a typo. It cleans up useless bits from address to simplify debugging.

Our binary does not fit into 512K - 64K (boot loader). All RW sections are in DDR memory and not in the binary. So we need to think how to implement own loader which will copy binary from NOR to DDR. One issue I can see that after changing of A18 and A19, boot loader from sector 0 is no longer available. 

Regards,

  Vladimir

Vladimir,

Regarding access of Sector 0, it might be because you are not resetting the GPIO?

Regards,
Vinesh

Vinesh,

I am speaking about following scenario:

- Existing boot loader modified and copies all data from NOR flash starting from sector 1 to DDR memory.

- when loader starts copping of sector 8 and later, it have to change GPIO output. At this step loader will crash, since it is executed from NOR address space (0x08000000) and content is changed because of GPIO output changed.

To avoid it we need to copy boot loader to the RAM and start pages copping and switching.

I have not implemented it yet. May be some other bottlenecks will be found also.

Regards,

  Vladimir

Vladimir,

Correct. As another option, it is possible to load the Copying code only to Internal/DDR memory. The GPIO can be reset after this function.

Regards,
Vinesh

Vladimir,

I just noted that this is already implemented in the SDK bootloader, except that it's for ICEv1. You can adapt this for ICEv2.

Regards,
Vinesh

Vinesh,

I still have an issue with NOR flash upper pages access. Last time I wrote that that memory content was changed, but it is not.

I expect that after changing of GPIO2_12 and GPIO2_13, memory content at addresses 0x080xxxxx should be changed and this change should be visible under debugger.

Changes I’ve made for isdk_nor_flasher.

main() function, GPIO initialization added

GPIOInitialization(2);
GPIOSetOutputPin(2,12);
GPIOSetOutputPin(2,13);

GPMCPinMuxConfNor() function, A18 and A19 initialization changed:

HWREG(CTRL_MODULE_BASE_ADDR + CONTROL_CONF_LCD_DATA(6)) =	//A18
		PINMUXMODE_8 |
			  CONTROL_CONF_LCD_DATA6_CONF_LCD_DATA6_RXACTIVE |
				 CONTROL_CONF_LCD_DATA6_CONF_LCD_DATA6_PUDEN;

HWREG(CTRL_MODULE_BASE_ADDR + CONTROL_CONF_LCD_DATA(7)) =         //A19
		PINMUXMODE_8 |
			  CONTROL_CONF_LCD_DATA7_CONF_LCD_DATA7_RXACTIVE |
				 CONTROL_CONF_LCD_DATA7_CONF_LCD_DATA7_PUDEN;

After initialization, I call:

    SetNORAddrGPIOPinForICE2(0x08000000); // sectors 0-7
    SetNORAddrGPIOPinForICE2(0x08080000); // sectors 8-15

And expect memory content changed.

Could you help me to solve the issue?

Thanks,
  Vladimir

Vladimir,

I expect that after changing of GPIO2_12 and GPIO2_13, memory content at addresses 0x080xxxxx should be changed and this change should be visible under debugger.

Depends on which address you are writing. If the address is below 0x8080000(512k), there is no need to trigger the GPIOs.

Again you'll have to call SetNORAddrGPIOPinForICE2 based on the sector you are writing. Calling it during init will not help.

Regards,
Vinesh

Vinesh,

I am trying to access after the first 512K. Address I need: 0x8080000 - 0x81ffffff.

After Initialization I am trying to access it:

    SetNORAddrGPIOPinForICE2(0x08080000);
// write secors 8-15
    SetNORAddrGPIOPinForICE2(0x08100000);
// write secors 16-23
    SetNORAddrGPIOPinForICE2(0x08180000);
// write secors 24-31

and can see memory content 0x8000000 - 0x81ffffff was not changed.

I expect immediate change in CCS Memory browser, after SetNORAddrGPIOPinForICE2 call.

Or some other steps should be done?

Regards,
 Vladimir

Vladimir,

What do you mean by you are trying to access it after initialization? 

By toggling the GPIO's, you should see information in 512k blocks in the CCS Memory browser. i.e., when you set

SetNORAddrGPIOPinForICE2(0x08080000);

you should be able to access address range - 0x08080000 to 0x08100000

Regards,
Vinesh

Vinesh,

you should be able to access address range - 0x08080000 to 0x08100000

The problem that nothing changed. 

It looks like GPIOEnableDisableOut(2,12, 1) takes no effect. Ma be initialization is wrong?

Could you look on attached files?

Regards,
Vladimir

6761.main.c  0753.norFlash.c

Vladimir,

I am observing the same behavior here, currently debugging the issue. Some observations

• Toggling GPIOs are resulting in different data on ICEv1
• Using ecat application[NOR], I tried toggling the GPIOs on ICEv2 and it had an effect on Memory browser/disassembly

So some config is missing for ICEv2 in the NOR flasher. Will keep you posted on the updates.

Regards,
Vinesh

Any update on why Vladimir's GPIO outputs for A18 and A19 don't work on ICEv2?

Also, why are A16 and A17 connected to gpmc_a1_mux2 (lcd_vsync mode 2) and gpmc_a2_mux2 (lcd_hsync mode 2) on ICEv2? Should A16 and A17 also be GPIO outputs?

Vladimir,

Apologies for the long delay.

On ICEv2, an external buffer is added to avoid conflict between SYSBOOT and other signals(PRU MII, GPIO etc). On power up, the buffer will be enabled by default and the SYSBOOT signals will be driven to the chip. We need to explicitly disable the buffer after power up to drive other functional signals multiplexed on the pins. The buffers are controlled using PRI_MII_CTL/GPIO3_4 pin. So you need to disable the buffers using GPIO3_4 to have the GPIO2_12/12 (GPMC A18/A19) take effect.

So adding these in the flasher(during initialization) should resolve this issue -

GPIOInitialization(3);
GPIOSetOutputPin(3,4);
GPIOEnableDisableOut(3, 4, 1);

Additionally, you would need to set the pinmux of GPIO3_4 to the correct mode as well.

Regards,
Vinesh