• State
  • Locked Locked
  • Replies 7 replies
  • Subscribers 83 subscribers
  • Views 653 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.

Original question:

Concerto M36 boot ROM API

F28M35H52C: Mapping UART0 Peripheral to Alternative Pins for Firmware Update Purposes

DO-Pro
Intellectual 610 points

Part Number: F28M35H52C

Hi,

We're working on F28M35H52C-based hardware development and planning to use UART0 for field firmware updates. Our problem here is that under current circumstances GPIO0 and GPIO1 are not available for UART0 as they're already used for other purposes. Instead, UART0 is mapped to GPIO28 and GPIO29 pins. While checking this forum, I've found the thread that discusses mapping UART0 peripheral to the alternative GPIO pins for purposes of firmware updates. Similar to that thread, we're planning to use Boot-to-OTP option and proceed with our own custom bootloader. The linked thread also mentions that TI was going to develop an example of using alternative UART0 mapping for firmware updates. Our questions are as follows.

Q1. Could TI share any relevant design guides, and/or firmware examples that would help in solving alternative UART0 mapping issue?

Q2. If no guides or examples are available, would you please provide us with any other guidance on the subject?

Thank you for your support.

Regards, Michael

  • 0
    TI__Mastermind 27550 points

    Hi Michael,

    I am not aware of an example like this (and are you currently using an particular example?), but let me look further into this and provide an update for you tomorrow.

    Best Regards,

    Allison

  • 0 in reply to Allison Nguyen
    Intellectual 610 points

    Hi Allison,

    No, we're not currently using any particular examples. This is our first attempt to re-assign UART0 to alternative pins and we're in quest of any relevant information and/or guidance on the subject.

    That said, we'll look forward for your update.
    Thank you for your assistance.

    Regards, Michael

  • 0 in reply to DO-Pro
    TI__Mastermind 27550 points

    Hi Michael,

    To clarify, are you trying to just use different GPIOs for UART0 (please correct me if I'm wrong)?

    There are several different sets of GPIOs that can be used for UART0 depending on your GPIO register settings as described in the device TRM in Table 4-2. GPIO Pins and Alternate Mode Functions:

    • GPIO0 and GPIO1
    • GPIO27 and GPIO28
    • GPIO35 and GPIO36
    • GPIO58 and GPIO59

    There is also section 4.1.4 Initialization and Configuration which has example UART GPIO configuration code. Please let me know if this info is at all helpful!

    Best Regards,

    Allison

  • 0 in reply to Allison Nguyen
    Intellectual 610 points

    Hi Allison,

    Yes, but... We clearly understand that peripheral could be re-assigned to alternative pins for application and have no problem with that. Our issue is that for communication with bootloader UART0 is assigned to PA0 and PA1 pins only as shown in the Table 6-8. These pins are already used in our application and we need bootloader to use GPIO28, 29. We'd like to make sure such re-assignment is possible as far as bootloader is concerned.

    Q3. Are there any restrictions that might prevent us from using GPIO28, 29 pins with UART0 specifically in custom bootloader? We intend to use Boot-to-OTP option.

    Regards, Michael

  • 0 in reply to DO-Pro
    TI__Mastermind 27550 points

    Hi Michael,

    Thanks for the clarification. There should be no restrictions to do reconfigure the UART pins (unless of course you were trying to use the boot pins (GPIO34, 35, 47, 43) which you'd have to configure alternate boot mode pins for). 

    Best Regards,

    Allison

  • 0 in reply to Allison Nguyen
    Intellectual 610 points

    Hi Allison,

    OK, so our plan then is to use Boot-to-OTP boot mode and place the start of our custom bootloader application at M-BOOT_ROM_OTP_ENTRY_POINT location. Inside that custom bootloader there will be some custom configuration function that, similar to TI’s ConfigureDevice() function, will configure UART0 peripheral. But contrary to ConfigureDevice(), our custom function will use alternative set of pins, which are GPIO28, 29. As a result, we expect that UART0 will then be capable of downloading flash content via that alternative set of pins as there’re no known restrictions preventing such re-configuring.

    Please confirm that this approach is correct or disprove it if you believe it’s wrong.

    Regards, Michael

  • 0 in reply to DO-Pro
    Intellectual 610 points

    Hi Allison,

    Would you please answer my question above?

    Thank you, Michael