• State
  • Locked Locked
  • Replies 14 replies
  • Subscribers 102 subscribers
  • Views 1832 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

16-bit boot NOR flash interfacing in A/D mode

Andrea Marson
Intellectual 800 points

We developed DM8148-based custom hardware.
We need some clarifications about interfacing 16-bit boot NOR flash in A/D mode.
NOR flash is Spansion S29GL01GS12DFIV10 (128 MByte).
The main problem we are facing is that CPU is able to address first 128 kByte of NOR flash only.

The following table summarizes how pin are connected. Lower 16 addresses are latched by 74ALVCH16373 latch driven by GPMC_ADVn_ALE signal.

CPU side (ball) ------- NOR side (ball)
GPMC_D0 (U26) - latch - A0 (E2)
GPMC_D1 (Y28) - latch - A1 (D2)
GPMC_D2 (V27) - latch - A2 (C2)
GPMC_D3 (W27) - latch - A3 (A2)
GPMC_D4 (V26) - latch - A4 (B2)
GPMC_D5 (AA28) - latch - A5 (D3)
GPMC_D6 (U25) - latch - A6(C3)
GPMC_D7 (V25) - latch - A7 (A3)
GPMC_D8 (Y27) - latch - A8 (B6)
GPMC_D9 (AB28) - latch - A9 (A6)
GPMC_D10 (Y26) - latch - A10 (C6)
GPMC_D11 (AA27) - latch - A11 (D6)
GPMC_D12 (U24) - latch - A12 (B7)
GPMC_D13 (U23) - latch - A13 (A7)
GPMC_D14 (V24) - latch - A14 (C7)
GPMC_D15 (Y25) - latch - A15 (D7)
GPMC_A16 (AD27) - NOT CONNECTED
GPMC_A17 (V23) - A16 (E7)
GPMC_A18 (AE28) - A17 (B3)
GPMC_A19 (AC27) - A18 (C4)
GPMC_A20 (AD28) - A19 (D5)
GPMC_A21 (AC28) - A20 (D4)
GPMC_A22 (AB27) - A21 (C5)
GPMC_A23 (AA26) - A22 (B8)
GPMC_A24 (L5) - A23 (C8)
GPMC_A25 (N23) - A24 (F8)
GPMC_A26 (P22) - A25 (G8)
GPMC_A27 (R24) - NOT CONNECTED

Attached are three images showing some CPU registers at boot:
- Control-Status-Reg-at-boot.png: it shows Control Status Registers
- GPMC-Misc-Regs-at-boot.png: it shows GPMC misc registers
- GPM-CS0-Regs-at-boot.png: it shows GPMC CS0 registers

Referring to Control-Status-Reg-at-boot.png:
ADMUX field of CONTROL_STATUS register is 10b = 2h.
SYSBOOT field of CONTROL_STATUS register is 11010b = 1Ah.
According to TRM sprugz8, this would correspond to the following configuration:
muxing scheme: Addr/Addr/Data Muxing
boot sequence: XIP (MUX0) - UART - SPI - MMC
So muxing scheme seems to be wrong for our NOR connection that is A/D.

However this configuration seems to be correct according to datasheet SPRS647B that says:
BTMODE[14:13]  01b = A/A/D muxed
BTMODE[14:13]  10b = A/D muxed

Our configuration seems to be correct according to section GPMC registers TRM sprugz8 too that says (see GPM-CS0-Regs-at-boot.png):
GPMC_CONFIG1_i.MUXADDDATA = 2h Address and data multiplexed attached device.

As said before, CPU is able to address first 128 kByte of NOR flash only. This is due to the fact that CPU does not move GPMC_A17 and higher address lines that are stuck to 0 even if we try to access area at address 0x0802:0000 and higher. However if we change (via JTAG debugger) field GPMC_CONFIG1_0.MUXADDDATA to 0 (Non-multiplexed attached device), when accessing address 0x0802:0000 CPU moves GPMC_A17 as expected. Thus GPMC_A17 pad has no electrical problems.

So we need to understand:
1) why CPU is unable to address whole flash in A/D mode
2) if our connection scheme is correct
3) which documentation is correct (TRM or datasheet); according to our test, datasheet is correct
4) why CPU moves A17 line only if we select demuxed mode via GPMC configuration register.

Thanks in advance.

16-bit-nor-boot-ad-mode.zip
  • 0
    TI__Genius 15310 points

    Hi IIandre,

    Could you give us your GPMC_ registers setting?  If GPMC_CONFIG bit 1 (LIMITEDADDRESS) is 1, then please change it to 0.

    BR,

    Viet

  • 0 in reply to Viet Dinh
    Intellectual 800 points

    Hi Viet,

    for your convenience I'll attach again GPMC miscellaneaus registers. As you can see LIMITEDADDRESS is already 0.

    Regards,

    llandre

  • 0 in reply to Andrea Marson
    TI__Genius 15310 points

    IIandre,

    Would you like to check your setup against this setup to see if it works for you?

    https://e2e.ti.com/support/dsp/davinci_digital_media_processors/int-dm814x/f/720/t/152204.aspx#553168

    BR,

    Viet

  • 0 in reply to Viet Dinh
    Intellectual 800 points

    Viet,

    could you please check the URL you provided? I can't access it ("Group Not Found").

    Thanks.

  • 0 in reply to Andrea Marson
    TI__Genius 15310 points

    IIandre,

    I copy and paste here:

    my customer has used these settings and got it to work with a NOR device they are using the Async interface for the NOR.

                                  .gpmc_nor_config.GpmcClkDivider == 0;
                                  .gpmc_nor_config.TimeParaGranularity == 0;
                                  .gpmc_nor_config.DeviceSize == device_size;
                                  .gpmc_nor_config.MuxAddData == 0x0;
                                  .gpmc_nor_config.WaitMonitoringTime == wait_time;
                                  .gpmc_nor_config.WaitWriteMonitoring == 0;
                                  .gpmc_nor_config.WaitReadMonitoring == 0;
                                  .gpmc_nor_config.ClkActivationTime == 0;
                                  .gpmc_nor_config.ADVExtraDelay == 0;
                                  .gpmc_nor_config.WEExtraDelay == 0;
                                  .gpmc_nor_config.AttachedDevicePageLength == page_length;
                                  .gpmc_nor_config.WriteType ==  0; -- Async
                                  .gpmc_nor_config.WriteMultiple == 0;
                                  .gpmc_nor_config.ReadType == 0; -- Async
                                  .gpmc_nor_config.ReadMultiple == 0;
                                  .gpmc_nor_config.WrapBurst == wrap_burst;
                                  .gpmc_nor_config.AccessTime == 2;
                    .gpmc_nor_config.ADVOnTime == 0;
                    .gpmc_nor_config.ADVRdOffTime == 1;
                    .gpmc_nor_config.ADVWrOffTime == 1;
                    .gpmc_nor_config.OEOnTime == 1;
                    .gpmc_nor_config.WEOnTime == 1;
                    .gpmc_nor_config.OEOffTime == 2;
                    .gpmc_nor_config.WEOffTime == 2;
                    .gpmc_nor_config.RdCycleTime == 3;
                    .gpmc_nor_config.WrCycleTime == 3;
                                  .gpmc_nor_config.BaseAddr == 0x0;
                                  .gpmc_nor_config.MaskAddr == 0x0;

     

  • 0 in reply to Viet Dinh
    Intellectual 800 points

    Viet,

    unfortunately the example you provided does not apply to our case because your customer uses nonmultiplexed mode (.gpmc_nor_config.MuxAddData == 0x0;) while we use A/D mode.

    Regards,

    llandre

  • 0 in reply to Andrea Marson
    Intellectual 800 points

    Viet,

    do have any news on this issue?

  • 0 in reply to Andrea Marson
    TI__Genius 15310 points

    IIandre,

    Have you done this for Mux Data?

    BR,

    Viet

  • 0 in reply to Viet Dinh
    Intellectual 800 points

    Yes, please refer to my first post.

    MUXADDDATA is set to 2h in order to select "Address and data multiplexed attached device".

    When this mode is selected, A17 and higher adresses are stuck to 0.

  • 0 in reply to Andrea Marson
    TI__Genius 15310 points

    Hi IIandre,

    I just found out that our TRM might be wrong, can you try this and let me know so I can change the TRM doc?  thanks.

    BR,

    Viet

  • 0 in reply to Viet Dinh
    Intellectual 800 points

    I think the new tables you posted is correct.

    We are not able to test the NOR functonality (our PCB has been designed on erroneous documentation). However it seems that A1 actually acts as A17 when working in AD mode.

  • 0 in reply to Andrea Marson
    Intellectual 800 points

    Viet,

    we are going to change PCB according to the corrected documentation. However it seems we found a bug in bootrom initialization.

    Bootstrap pins are set up as follows:


    BTMODE[14:13]  10 = A/D muxed
    BTMODE[12]  1 = 16-bit data bus
    BTMODE[10] 1 = GPMC Option B

    We expect GMPC_A[12..1] pads (ball J28,K27,M24,L26,AD18,AC18,AC19,AA22,AE23,AD23,AB23,AF18) are configured as addresses as described in table 4-2. "XIP (on GPMC) Boot Options" on page 155 of datasheet SPRS647C. It seems they are configured in safe mode instead and pull-ups are enabled. This prevents U-Boot to be executed because CPU is not able to address NOR flash properly.

  • 0 in reply to Andrea Marson
    TI__Prodigy 515 points

    Hi

    Since A/D muxing is being used, BootROM doesnt configure the higher address lines as mentioned in the above table.

    Boot ROM only configures the AD0-AD15 lines.

    Higher address lines needs to be pulled low to access the NOR flash.

    Regards

    Gaurav Garg

  • 0 in reply to Gaurav Garg (HWApps)
    Intellectual 1000 points

    Thanks for the confirm Gaurav,

    I would like to reduce the impact of active pull down on GPMC_A[1..11] pins. I've seen, with a JTAG debugger, that, at the beginning of u-boot code, some of this pins are already pulled down by default. We can avoid additional logic on those pin if we can identify them for sure.

    Is there a table, on TRM or datasheet, where this default configuration is explained in detail?

    Best Regards,

    Andrea