• State Resolved
  • Locked Locked
  • Replies 5 replies
  • Subscribers 104 subscribers
  • Views 720 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

TMDSLCDK6748: Writing to NAND Flash fails for large images

Ad van de Voort
Intellectual 280 points
Part Number: TMDSLCDK6748
Other Parts Discussed in Thread: OMAP-L138, TMS320C6748

Hi,

When using AISgen and CCS project NANDWriter_DSP to write a large image (68 KB or more) to the NAND Flash of the TMDSLCDK6748 board the tools do not report an error, but when restarting the board nothing happens. It works fine when the image is smaller (45 KB or less). Also the large image works fine when loaded with the debug probe.

Here are the hardware and software that are used:

What could be wrong?

Best regards,

Ad

  • 0
    TI__Guru 65405 points
    Hi Ad,

    The team is notified. They will post their feedback directly here.

    BR
    Tsvetolin Shulev
  • 0 in reply to Cvetolin Shulev-XID
    Intellectual 280 points

    Hi,

    Update:

    At first I couldn't get UART2 to reply BOOTME on startup, then I found that the OMAP-L138/C6748 LC Dev Kit A7E Schematic (sprcaf4) has specified the incorrect boot mode settings for UART2!

    After setting the correct boot mode settings for UART2 I started the program UartHost.exe (OMAP-L138 UART Boot Host, Ver 1.3) that came with the AISgen v1.13 software. But it failed for both small and large images, see the output below.

    Is the UartHost.exe only for OMAP-L138 or can it also be used for C6748 (as I am doing)? If not what tool do I need to write an image to the NAND flash of the C6748 with the UART?

    (File IO): Read 31712 bytes from file C:\TITAN\ws_ccs\HWorldC6748\Release\HWorldC6748_AIS_out.bin.
    (Serial Port): Opening COM3 at 115200 baud...
    (AIS Parse): Read magic word 0x41504954.
    (AIS Parse): Waiting for BOOTME... (power on or reset target now)
    (AIS Parse): BOOTME received!
    (AIS Parse): Performing Start-Word Sync...
    (AIS Parse): Performing Ping Opcode Sync...
    (AIS Parse): Processing command 0: 0x58535901.
    (AIS Parse): Performing Opcode Sync...
    (AIS Parse): Loading section...
    (AIS Parse): Loaded 704-Byte section to address 0x00800020.
    (AIS Parse): Processing command 1: 0x58535901.
    (AIS Parse): Performing Opcode Sync...
    (AIS Parse): Loading section...
    (AIS Parse): Loaded 288-Byte section to address 0x008002E0.
    (AIS Parse): Processing command 2: 0x58535901.
    (AIS Parse): Performing Opcode Sync...
    (AIS Parse): Loading section...
    (AIS Parse): Loaded 64-Byte section to address 0x00800400.
    (AIS Parse): Processing command 3: 0x58535901.
    (AIS Parse): Performing Opcode Sync...
    (AIS Parse): Loading section...
    (AIS Parse): Loaded 16-Byte section to address 0x00800440.
    (AIS Parse): Processing command 4: 0x58535905.
    (AIS Parse): Performing Opcode Sync...
    (AIS Parse): Performing jump...
    (AIS Parse): Jump to address 0x00800220.
    (AIS Parse): Processing command 5: 0x5853590D.
    (AIS Parse): Performing Opcode Sync...
    (AIS Parse): Executing function...
    (AIS Parse): Processing command 6: 0x5853590D.
    (AIS Parse): Performing Opcode Sync...
    (Serial Port): Read error: The operation has timed out.
    (AIS Parse): I/O Error in read!
    (Serial Port): Read error: The operation has timed out.
    (AIS Parse): I/O Error in read!
    (Serial Port): Read error: The operation has timed out.
    (AIS Parse): I/O Error in read!
    (Serial Port): Read error: The operation has timed out.
    (AIS Parse): I/O Error in read!
    (Serial Port): Read error: The operation has timed out.
    (AIS Parse): I/O Error in read!
    (Serial Port): Read error: The operation has timed out.
    (AIS Parse): I/O Error in read!
    (Serial Port): Read error: The operation has timed out.
    (AIS Parse): I/O Error in read!
    (Serial Port): Read error: The operation has timed out.
    (AIS Parse): I/O Error in read!
    (Serial Port): Read error: The operation has timed out.
    (AIS Parse): I/O Error in read!
    (Serial Port): Read error: The operation has timed out.
    (AIS Parse): I/O Error in read!
    (Serial Port): Read error: The operation has timed out.
    (AIS Parse): I/O Error in read!
    (AIS Parse): Opcode Sync failed after 11 consecutive I/O failures.
    (AIS Parse): Boot aborted.
    (Serial Port): Closing COM3.

  • 0
    Guru 26430 points
    My first guess, would be that you are crossing NAND block boundaries and something is wrong with the next block. But...the NAND device block size is 128KB. A write of 45KB or 68KB should be using the same code, same block. Both should work.

    My guess would be that the extra code is not getting prerequiste HW initialization. The extra code may hang, The increase from 45KB to 68KB would suggest a large amount of code.

    When executing using the debug probe, a large number of initializations occur in the GEL script. Executiion from NAND requires those initializations to occur in either additional init code or as additional init is the AISGEN.

    I vaguely remember the schematic has boot settings that are for the processor boot pins. The DIP switch is inverted. The "1" position on the DIP really means 0 at the processor pins.
  • 0 in reply to Norman Wong
    Intellectual 280 points

    Hi Norman,

    Thank you for your suggestions. But I found out that the problem was the placement of the image in the DSPL2RAM in combination with the application of the patch as described in Advisory 2.3.24 of the document: "Silicon Errata, TMS320C6748 ... revisions 2.3,  ...".

    "My guess would be that the extra code is not getting prerequiste HW initialization. The extra code may hang, The increase from 45KB to 68KB would suggest a large amount of code."

    Good point, but the extra code was added to the image without actually being called.

    "When executing using the debug probe, a large number of initializations occur in the GEL script. Executiion from NAND requires those initializations to occur in either additional init code or as additional init is the AISGEN."

    Yes indeed, I thought of that: all initialization inside the GEL that was not done by AISgen was moved to the code.

    Thus it was the code/data that was placed DSPL2RAM that was the cause: the Silicon Errata. Advisory 2.3.24 states:

    "Memory usage of the patch at boot time is as follows: - 1 KB at location 0x1180 0000".

    I changed the following two lines in the C6748.cmd file:

        DSPL2RAM     o = 0x00800000  l = 0x00040000   /* 256kB L2 Internal RAM */
        SHDSPL2RAM   o = 0x11800000  l = 0x00040000   /* 256kB L2 Shared Internal RAM */

    into:

        DSPL2RAM     o = 0x00800400  l = 0x0003FC00   /* 255kB L2 Internal RAM */
        SHDSPL2RAM   o = 0x11800400  l = 0x0003FC00   /* 255kB L2 Shared Internal RAM */

    and the problem is gone for both small and large images.

    Is this the correct way to solve the problem?

    I guess the reason that small images were causing no problem is because that part did not contain any bit errors in the pages for which the patch is a workaround. For larger images probably were written to pages with bit errors and the patch in the location 0x1180 0000 was overwritten by the code/data loaded from the image.

    "I vaguely remember the schematic has boot settings that are for the processor boot pins. The DIP switch is inverted. The "1" position on the DIP really means 0 at the processor pins."

    The boot switches are inverted and reversed with respect to the boot pins. Inverted: a ON or "1" position on the switch corresponds to a LOW or "0" signal on the boot pin; Reversed: there are 8 boot pins from 0 to 7 and boot pins 1 to 4 are connected to the switches reversed (other boot pins are always 0): sw1 connects to boot pin 4, sw2 to pin 3, sw3 to pin 2 and sw4 to pin1. The schematic specifies NAND FLASH: 0111 and UART2: 1010, the NAND flash is only correct if the order is interpreted as <sw1><sw2><sw3><sw4> and the "1" position is ON. With the same interpretation the UART2 is not correct.

    Best regards,

    Ad

  • 0 in reply to Ad van de Voort
    Guru 26430 points
    Wow. That is quite an obscure bug in the RBL. Reserving 1KB and using the patch is reasonable approach for robustness. Short of of replacing the NAND. Or moving the next good block in NAND. The NAND writer would require considerable mods to find block that will write clean without bit errors.

    Personally, I loath giving up 1KB of L2 RAM. Maybe you can put some run time intialized section at that spot.

    Thanks for the detailed response.