AM2612: Needs the RS485 example code for AM2612

Part Number: AM2612
Other Parts Discussed in Thread: SYSCONFIG

Champs:

  #1. In our M0, we have the RS485 example code.

        See here:

        https://dev.ti.com/tirex/explore/node?node=A__AHyw45GTYS2bYxKBSXevuQ__MSPM0-SDK__a3PaaoK__LATEST

 

  #2. Now, my cust is using the AM2612, they need the RS485 example code as well.

 Plz help.

Thanks.

BR Rio

  • Rio,

    Let us connect you with the right expert on this.

    Best Regards,

    Aishwarya

  • Hey Rio,

    I am looking into this for you. We should be able to port the CortexM33 code for RS485 to work with AM2612, but they are different UART IP modules at the heart of the devices so we will need to make sure we have the proper UART configuration from SysCtl.

    Has the customer attempted to port the code themselves yet?

    Best Regards,

    Zackary Fleenor

  • Hi Zack:

    Cust is starting to porting the 485 code, please provide an example for the Backup if they failed.

    Thanks.

    BR Rio

  • Hey Rio,

    Thanks for the update. I've done some analysis on the feasibility of porting the MSPM0 RS485 example to the AM2612. Here's what I found:

    Key Differences to be Aware of:

    1. Core Architecture

    • MSPM0 uses a Cortex-M33 core
    • AM2612 uses a Cortex-R5F core
    • The core logic of the RS485 application code should be portable, but any CMSIS-based or M33-specific intrinsics will need to be replaced with R5F equivalents from the MCU+ SDK

    2. UART/RS485 IP Differences

    • MSPM0 uses TI's UART module configured via SysConfig/DriverLib
    • AM2612 uses the UART (16550-compatible) peripheral, configured via MCU+ SDK drivers
    • The customer will need to replace all MSPM0 DriverLib UART calls with the corresponding MCU+ SDK UART LLD/HLD driver APIs

    3. SDK & SysConfig Differences

    4. RS485 Direction Control (Critical)

    • On MSPM0, RS485 direction control can be handled via the built-in UART hardware flow control or GPIO toggling
    • On AM2612, the customer should check whether the UART peripheral supports hardware RS485 direction control (DE pin) or if they need to implement manual GPIO toggling around transmit/receive transitions
    • I'd recommend reviewing the AM2612 TRM, Section on UART, to confirm RS485 mode support

    5. Interrupt/DMA Handling

    • Interrupt vector table structure is different between M33 and R5F
    • If the MSPM0 example uses DMA, the customer will need to remap to the AM2612 UDMA/PKTDMA accordingly

    Recommended Porting Steps for the Customer:

    1. Start with the MCU+ SDK UART echo example on AM2612 as a baseline
    2. Enable and configure the UART in RS485 mode via SysConfig
    3. Implement DE/RE GPIO control if hardware RS485 direction control is not natively supported
    4. Port the application-level RS485 logic from the MSPM0 example
    5. Validate TX/RX framing and direction switching timing on a scope

    Rather than duplicating the current customer effort on our side, it would be easier to work collaboratively along with customer on their porting effort to address any issues that arise. Feel free to share the current code base here or offline as a starting point of reference.

    In the meantime, please let us know if the customer has any specific questions as they work through the porting process.

    Best Regards,

    Zackary Fleenor

  • Hi  

    I have responded offline with a driver changes and a loopback example

    Regards,
    Shaunak

  • Hi Shaunak:

    This can be closed since my cust make it work, btw, thanks for your delivery, I will back up this.

    BR Rio