• State Resolved
  • Locked Locked
  • Replies 5 replies
  • Subscribers 55 subscribers
  • Views 684 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:

CC1352P: ZigBee Linux Gateway active product?

CC1352P: ZigBee Linux Gateway: serial communication

Peter Hoyer
Expert 1400 points
Part Number: CC1352P
Other Parts Discussed in Thread: Z-STACK

On an ARM-based device with Z-Stack Linux Gateway installed, there is a CC1352P module. For testing purposes I have also connected a CC1352P Launchpad.

The same firmware (CC1352P2LP_GW_ZNP_UART.hex) is installed on the module as well as on the Launchpad. The firmware is correct (verify done).

If I start the gateway using the internal module, communication fails, If I use the Launchpad, it works fine.

Excuding wrong ports in the configuration file, reset GPIO set to HIGH or other erros, what could cause the gateway communicating with my module? The serial communication is working as I have used it for the update as well. Is there anything special - other than just connecting to /dev/ttyACM0 what the gateway software is doing with the Launchpad? Are there any specific DIO states (other than backdoor) required for the ZNP firmware to run correctly?

  • 0
    TI__Guru**** 219597 points

    There is nothing other than the UART interface required to communicate between the ZNP and host controller.  Can you verify that the internal module is supplied proper power and that the ZNP firmware is actively running?  Are you able to provide schematics and board design files of the custom PCB?  You mention using the backdoor bootloader (SWRA466) so please confirm that this state is not active.  It may also help to confirm the custom design works with a Windows Z-Tool host interface. 

    Regards,
    Ryan

  • 0 in reply to Ryan Brown1
    Expert 1400 points

    Hi Ryan,

    Thank you for the quick reply. Is it possible to send a private message through here or to mark parts of the message as non-public?

    Regards
    Peter

  • 0 in reply to Peter Hoyer
    Expert 1400 points

    Hi Ryan,

    Answering in general terms:

    The module seems to be well-connected. We are using an internally developed update tool for the firmware upload. As we are using the serial interface, this takes about 15 minutes and it works without errors. So I would exclude a power issues or RX/TX problems.

    We have set DIO18 as backdoor. So if low the module goes into bootloader mode, if HIGH it starts the application. We have measured that the GPIO is set correctly and in addition, the firmware tool will only work of DIO18 is LOW, so that looks good as well. RESET is needed for the firmware tool, so also this is working OK.

    Like a miracle, 2 times I was able to successfully connect to the application. It was both times immediately after the update when changing DIO18 and sending a reset. But no idea why this happened and how to reproduce.

    I would also exclude our firmware uploader application as a potential source of the problem as it works fine with Launchpad.

    The module is connected through a SILabs CP2108 to the CPU which is a Raspberry CM3+.

    Any ideas? For more specific details about the hardware, I would prefer a private message.

    Regards
    Peter

  • 0 in reply to Peter Hoyer
    TI__Guru**** 219597 points

    Hi Peter,

    I've sent you a friend request, after accepting you can send me a private message.  It would be best if you could discover the conditions around which you are able to connect successfully.  This at least confirms that the proper systems are in place.  You may want to sanity check the UART lines with an oscilloscope or power analyzer.

    Regards,
    Ryan

  • 0 in reply to Ryan Brown1
    Expert 1400 points

    Hi Ryan,

    Thank you for your support. At the end it was the reset GPIO which is connected to the module with an inverted logic. When using HIGH for LOW and vs. versa. By taking this into account, everything works perfect.

    Regards
    Peter