Main Site Documentation

Can not deploy to MedusaMini with RS485 connected


I have the following setup:


  • PROG (4): USB Serial
  • X (3): Temp & Humidity
  • S (1): N18 display
  • U (2): Extender - RS485
    (all original GHI modules)

Via socket 2 I inject power by a Extender Module and a USB Client SP. only pin 1, 2, and 10 are connected to USB Client module.

With this configuration I can not deploy any program:

btw. I have to manually reset the board for deploy right after compilation, GUS mentioned something like that when I use this config. May be it's important here).

If I disconnect the RS485 it works.
I do not make any changes to the application.

The RS485 is not initialized in the application.

The debug monitor seams to work all the time (I see my Serial.println's when I reset the board)

Any ideas?
is the bootloader using the wrong usart?

Arduino IDE 1.5.5 beta
VS 2013 + VisualMicro plugin (same behaviour with Arduine IDE)
Gadgeteering SDK 2013 R1 (beta) with N18 fix for stepping

Edit: one more info:
when I initialize the RS485, then my program seams to stop after 1st Serial.println and and additional "?n" is written in serial monitor after each new line.
I know that RS485 Gadgeteering driver is not tested, bit it's not really more than a wrapper around devices::serial.

I tried initializing RS485 before Serial.begin(9600)

serial_configuration sc;
	sc.baud_rate = 9600;
	sc.data_bits = 8;
	sc.stop_bits = serial_configuration::stop_bits::ONE;
	sc.data_parity = serial_configuration::parities::EVEN;
	_modbus = new ModbusRtu(2, sc);

	// put your setup code here, to run once:

By this I get only %$§&bla in the Debug monitor.
Is it possible that Medusa mini has only one USART which is shared between socket 2 and 4 !?

ZEZMedusaMini.cpp assigns SERIAL_0 to socket 2:

Is this correct?


I think I just answered my question by my self:
According to the schematic the RXD/TXD pins of socket 2(U) and 4 (PROG) are identical.
This means that the U Port can not be used when programming interface is attached.

The only hint you can find for this are the schematics and:
"When uploading your compiled code your should remove any “U” type modules. They can be re-attached after uploading is complete."
Even that I read this sentence before I bought my Medusas, but I did not even think that this might influence normal operation.
This fact should be made way more clearer!

In fact it’s not an complete show stopper for my project, because finally only RS485 module will be connected, but I can not even do “Serial.println” debugging when a U module is connected.
This makes development way harder.

But I have one more question now:
Can I even use the line Serial.begin(9600) when U module is connected, or do I have to remove this line then?


You are correct in that Socket 2 and 4 do indeed use the same UART pins. So if you have something plugged into Socket 2 that is using pin 4 and 5, it can prevent uploading a program to the board. The only solution is to unplug the thing in Socket 2.

Generally you do not need to call Serial.begin when using our serial classes and modules. It is all handled for you. If you have a module on socket 2, though, there can be collisions with the debug output. Serial.println(); just writes to the one UART that is shared on socket 2 and 4.


Yes, with your setup this is expected. The difference between the USB Serial module and USB Serial SP module is that the reset pin is connected to work with arduino in the SP variant. Without this, it will take a carefully timed manual reset to allow code to deploy.