• State
  • Locked Locked
  • Replies 1 reply
  • Subscribers 55 subscribers
  • Views 632 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.

CC2538: User boot-loader programming flash (app) via USB data corruption

MonkeyBusiness
Expert 2030 points
Part Number: CC2538

I have a custom boot-loader at 0x0021-0000 and an app at 0x0024-8000. The app is approximately 0x10000 long. When flash down-loading, with the custom boot-loader, a small block of 44 32-bit words is corrupted. Trapping on that packet, it appears that they are corrupted in the USB buffer. It repeatable in the same place every time. Wireshark & console monitor shows that the Windows app is sending the correct data.

The custom-user-boot-loader makes calls to FlashMainPageProgram() in the foundation firmware, which really calls programming functions in ROM. I disable interrupts before the FlashMainPageProgram() call and enable them after. I found that if I left the interrupts enabled I ran into more issues.

The TI M3 allows running out of flash while programming flash. However, it really does not make clear what the policy is on having interrupts enabled during this flash programming is! It would seem to me that as long as the interrupts only make calls to the custom boot-loader area, it should not be a problem. But, that is not the case.

The reason I mention this is that perhaps there is some timing issue, where the USB cannot service interrupts at a critical point with the PC. However, this would be limited to just control messages as the actual boot-loader communications are poll-response. That is, data is sent to the 2538, the 2538 turns of interrupts,  programs the data, and then sends back a status. The data programmed is small packets of 100 (decimal) so it is fairly quick. Oddly, I don't have an issue on the initial erase where many blocks are erased and it takes several seconds. The USB packets that come in right after that are fine.

It may not be related to interrupts at all. But this describes what is procedure is.

Any ideas?

  • 0
    TI__Prodigy 220 points

    Hey,

    My hunch is that the flash write operation is taking too long, and starving the USB controller of interrupt handling.

    According to Section 8.1 of the cc2538 TRM, a flash write of 4 bytes will take a minimum of 20 microseconds. If you are programming 100 bytes at a time, that would take a minimum of 500 microseconds. Theoretically, the USB controller, operating at 12 Mbps, could fill a 750 byte buffer in 0.5 milliseconds. Of course, these are rough estimates, the USB may take longer to transfer the data and the Flash FSM may take longer to program the data.

    Try slowing down the transfer from the Host PC side and see if that alleviates the issue, or moves the error segment.

    You might also program the Flash in smaller chunks to allow the servicing of interrupts, 500 microseconds is a fair amount of time to starve the interrupt controller.

    If this issue persists, you may consider adding some framing to the data, and asking the Host PC for retransmission of frames that do not have a matching Frame Check Sequence.

    Section 8.3.1 of the cc2538 TRM states that the CPU cannot access flash during a flash write or erase. Code must be in ROM or SRAM for the CPU to execute it during a Flash program or erase. If interrupts were enabled during a Flash program and one were to fire, the CPU would fetch instructions from Flash, causing memory corruption.

    The Flash programming function in ROM will disable instruction prefetching, but you will also want to make sure that all interrupts are disabled with CPUcpsid() and that the CPU does not enter power modes 1, 2, or 3. You can re-enable the interrupts with CPUcpsie() if CPUcpsid() disabled them.

    Thanks,

    Seth