Flash your board using USB to Serial or STLink (or another SWD device e.g. JTAG or Black Magic Probe etc). If you use a Maple Mini or Maple Mini clone, you can update the bootloader by uploading the updater sketch; Update using the updater sketch.

Code: // Enable debug prints to serial monitor #define MY_DEBUG //#define MY_DEBUG_HWSERIAL Serial // = Serial0 / Rx0 & Tx0 to programming & debug // Enable RS485 transport layer #define MY_RS485 // Define this to enables DE-pin management on defined pin #define MY_RS485_DE_PIN 11 // Set RS485 baud rate to use #define MY_RS485_BAUD_RATE 38400 // Enable this if RS485 is connected to a hardware serial port #define MY_RS485_HWSERIAL Serial1 // Enable serial gateway #define MY_GATEWAY_SERIAL #define MY_SERIALDEVICE Serial // Rx* & Tx* to Gateway. Serial & USB Serial Serial USB is enabled for all F103 boards when uploading using the bootloader, it is also available when uploading by ST-Link (SWD) In these cases: Serial.print('Hello world'); will print via Serial USB (CDC). Serial1 prints to hardware USART 1 Serial2 prints to hardware USART 2 etc When uploading via 'Serial' (external USB to Serial adaptor connected to PA9 and PA10 (USART1) on the STM32): Serial.print('Hello world'); will print to hardware USART1 (the one the code was uploaded using) Serial1 prints to hardware USART 2 etc Note. Some boards, e.g. Nucleo F103RB have special serial mapping, because these boards need to have hardware modification to make Serial usable. The Serial USART mapping is defined in file 'variants//board.cpp'.

Fri Feb 09, 2018 3:28 pm. Not the best Idea was to connect the receive und transmit Pins to 16/16 at the MAPLE. I would be happy if there is a easy way to redifine UART 1 to this pins. Is this possible? -If not i would change the hardware. Er, half-duplex? The default pin mapping with the current core for Maple Mini is above.

We prefer in this forum to NOT reference pins. They have mixed meaning, so talk about ports, PA2 and PA3 would be port A,2 (Tx2) and port A,3 (Rx2). These are the signals specified on the uC itself. This.h file explains how the UARTS are mapped to resource pins: In summary. Code: #define DEFINE_HWSERIAL(name, n) HardwareSerial name(USART##n, BOARD_USART##n##_TX_PIN, BOARD_USART##n##_RX_PIN) #define DEFINE_HWSERIAL_UART(name, n) HardwareSerial name(UART##n, BOARD_USART##n##_TX_PIN, BOARD_USART##n##_RX_PIN) /* Roger clark. Changed class inheritance from Print to Stream. * Also added new functions for peek() and availableForWrite() * Note.

AvailableForWrite is only a stub function in the cpp */ class HardwareSerial: public Stream { public: HardwareSerial(struct usart_dev *usart_device, uint8 tx_pin, uint8 rx_pin); /* Set up/tear down */ void begin(uint32 baud); void begin(uint32 baud,uint8_t config); void end(). Code: USART (serial port) related constants: BOARD_USART1_TX_PIN, BOARD_USART2_TX_PIN, BOARD_USART3_TX_PIN: TX pins for the 3 USARTS. BOARD_USART1_RX_PIN, BOARD_USART2_RX_PIN, BOARD_USART3_RX_PIN: RX pins for the 3 USARTS. BOARD_UART4_TX_PIN, BOARD_UART5_TX_PIN: TX pins for UARTs 4 and 5 (high-density boards like Maple Native only). BOARD_UART4_RX_PIN, BOARD_UART5_RX_PIN: RX pins for UARTs 4 and 5 (high-density boards like Maple Native only).

BOARD_NR_USARTS: Number of serial ports on the board. This number includes UARTs 4 and 5 if they are available.

And reference this link: Hacking: If you are competent to dig into the core serial code, go for it but the forum almost always recommends to keep yourself out of the core code because you will break stuff on the next core update (unless extensive measures are taken to prevent code overwrite.) It's your choice but do not come crying here as I certainly will have little sympathy for your situation. This statement on Leaflabs is no longer accurate for the STMduino core. Sat Feb 10, 2018 10:08 am. I recall someone posted how to remap those pins Aargh! • In one case, the procedure failed • In another case, the remapping worked but 3rd party libraries failed with initialization issues Remapping of internal fabric comes with many caveats, too many to support IMO as a forum solution.

The hardware being used is not like the PSoC where pin remapping is a graphical drag&drop operation. Scm xilog programming. Even with PSoC, some pins refuse to remap. So, I cannot recommend remapping as a solution within the confines of this Forum. There is simply not sufficient time to work with the user's sketch, the libraries, and a frustrated user in hopes that voodoo mapping will solve an issue.