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.

freemodbus on MSP430FR5728

Other Parts Discussed in Thread: MSP430FR5728, MSP430F169, MSP430F2274

I would like to implement modbus ASCII on an MSP430FR5728 device (using a SN65HVD12D transceiver on the PCB)

I found the freemodbus library (http://www.freemodbus.org/) which also has an implementation for an MSP430F169.

In the F169 there is a USART block, but in the FR5728 there is an eUSCI block.

As expected, when compiling (in CCS) I get a lot of unknown registers.

I don't want to spend a couple of days trying to port the code to the other chip, just to discover in the end that it is impossible for some reason, so my questions are:

1) Is it possible to implement modbus on the MSP430FR5728 with small modifications to the MSP specific code of the freemodbus library?

2) has anybody else already ported it to a similar chip (that has an eUSCI block instead of USART)?

  • Hi Bart,

    I don't know lots about MODBUS, but it is normally really a protocol implemented on top of UART/RS232 as the physical layer correct? If this is true, then you definitely should be able to get this to work with eUSCI. The eUSCI module is actually in general a lot easier to handle serial communications like UART with than the USART module. I'd recommend taking a look at the eUSCI UART code examples for MSP430FR5728 to get an idea of how to set up the eUSCI for UART mode, and get that working first - then start incorporating it into your protocol stack.

    Regards,

    Katie

  • Bart,

    These documents might also be helpful for you:

    Migrating from MSP430F16x to MSP430F261x: www.ti.com/lit/pdf/slaa380 contains a section (3.2) on differences between USART and USCI. While FR57xx has eUSCI, it is much more similar to USCI than USART.

    Migrating from USCI to eUSCI: www.ti.com/lit/pdf/slaa522 will help you with additional differences from the USCI discussed in the previous document.

    Finally you may also want to see this for differences regarding FR57xx in general: Migrating from F2xx to FR57xx family: http://www.ti.com/lit/pdf/slaa499

    Regards,

    Katie

  • Finally some Modbus activity again, very nice.

    Couple of years ago I also started with Modbus for our applications, and also used the freemodbus example for F169.

    I converted the code into my MSP430F2274, as you already said this took some time, about a week or less, on the MSP430 i had less difficulties than on the debug side once trying to communicate with the PC, since there are not a lot of modbus tools as Terminal programs.

    So thats why I would say it definetly works, you just have to switch the UART routines to your Ports and Pins and IRQs.

  • I have made some progress: alle periferals (UART and timer) seem to work ok, I can send and receive frames, but now I ran into a software problem:

    In the mb.c file (see attached zip with total project) there is a definition of the handlers (pointers to user implemented callback functions):

    static xMBFunctionHandler xFuncHandlers[MB_FUNC_HANDLERS_MAX] = {
    #if MB_FUNC_OTHER_REP_SLAVEID_ENABLED > 0
       {MB_FUNC_OTHER_REPORT_SLAVEID, eMBFuncReportSlaveID},
    #endif
    #if MB_FUNC_READ_INPUT_ENABLED > 0
        {MB_FUNC_READ_INPUT_REGISTER, eMBFuncReadInputRegister},
    #endif
    #if MB_FUNC_READ_HOLDING_ENABLED > 0
        {MB_FUNC_READ_HOLDING_REGISTER, eMBFuncReadHoldingRegister},
    #endif
    #if MB_FUNC_WRITE_MULTIPLE_HOLDING_ENABLED > 0
        {MB_FUNC_WRITE_MULTIPLE_REGISTERS, eMBFuncWriteMultipleHoldingRegister},
    #endif

    ...

    When I start the program, the values that where initialised (MB_FUNC_READ_INPUT_REGISTER, MB_FUNC_READ_HOLDING_REGISTER, ...) are all zero for some reason, right from the start of the program.

    During compilation I get the following warning:
    #10229-D output section ".data" refers to load symbol "eMBFuncReportSlaveID" and hence cannot be compressed; compression "rle" is ignored    RS485CT             C/C++ Problem
    Could this be the cause?, if so, how can it be fixed?

    I tried recompiling the relevant part (see end of this post) only, in a separate project, and there it works.

    This project was originally made for Rowley and gcc, And I am using TI's CCS: Could that have something to do with it?

    As said in previous posts, I am using the MSP430FR5728 and compiling with CCS, while the project was originally made for MSP430F169, using Rowley or gcc.

    This chip has less RAM than the original one, might that be causing the problem? I suppose the default for the compiler is to put the variables in RAM, can I instruct it to put it in the FRAM to?

    UPDATE:
    I defined an FRAM_DATA section in the linker command file and put "#pragma DATA_SECTION(xFuncHandlers, ".FRAM_DATA")" before the declaration of the xFuncHandlers variable.
    The result is the same: values are still zero

    Does anybody have any idea what might be causing this?

    Regards,

    Bart

    RELEVANT CODE SECTION:

    typedef unsigned char UCHAR;
    typedef unsigned short USHORT;
    typedef enum
    {
    MB_EX_NONE = 0x00,
    MB_EX_ILLEGAL_FUNCTION = 0x01,
    MB_EX_ILLEGAL_DATA_ADDRESS = 0x02,
    MB_EX_ILLEGAL_DATA_VALUE = 0x03,
    MB_EX_SLAVE_DEVICE_FAILURE = 0x04,
    MB_EX_ACKNOWLEDGE = 0x05,
    MB_EX_SLAVE_BUSY = 0x06,
    MB_EX_MEMORY_PARITY_ERROR = 0x08,
    MB_EX_GATEWAY_PATH_FAILED = 0x0A,
    MB_EX_GATEWAY_TGT_FAILED = 0x0B
    } eMBException;


    typedef         eMBException( *pxMBFunctionHandler ) ( UCHAR * pucFrame, USHORT * pusLength );

    typedef struct
    {
        UCHAR           ucFunctionCode;
        pxMBFunctionHandler pxHandler;
    } xMBFunctionHandler;

    #define  dertien  (13)
    #define MB_FUNC_HANDLERS_MAX                    ( 16 )
    eMBException    eMBFuncReportSlaveID( UCHAR * pucFrame, USHORT * usLen );

    static xMBFunctionHandler xFuncHandlers[MB_FUNC_HANDLERS_MAX] = {
            {dertien,eMBFuncReportSlaveID},
        {dertien, eMBFuncReportSlaveID}
    };

    RS485CT.zip
  • Bart Van Thielen said:

    I defined an FRAM_DATA section in the linker command file and put "#pragma DATA_SECTION(xFuncHandlers, ".FRAM_DATA")" before the declaration of the xFuncHandlers variable.
    The result is the same: values are still zero

    Did you try the NOINIT or PERSISTENT Pragma?

  • I see you are using an old compiler version, it’s advisable to keep your CCS updated especially when using FRAM MCU’s. After update compare your Linker Command file with the newer updated default file.

  • I added NOINIT to the linker command file, and now it works!

    It answers on the modbus with the register contents as well.

    Thank you!,

    Bart

**Attention** This is a public forum