As the title suggest I would like to use swo for debugging on an stm32F1 device without the use of st-link utils.I think I have flashed the code to send messages via swo on my chip but I can not establish a connection with the correct port as some tutorials suggested I use putty with the telnet port 2332 .
Specifics about my configuration:
Relative code on my main
int _write(int file, char *ptr, int len)
{
int DataIdx;
for (DataIdx = 0; DataIdx < len; DataIdx++)
{
__io_putchar(*ptr++);
}
return len;
}
...
int main(){
while (1)
{
printf("Hi\n");
}
}
I have seen some tutorials using eclipse configurations or st-link utils but I have a very custom toolchain (I use conan, obko cmake configurations https://github.com/ObKo/stm32-cmake , ocb and linux) for the sole purpose of using c++ 2017 and libraries like boost so I can not use st-link utils.
You need to enable ITM port 0 (or another one) then output the chars using this port.
When it works you can wrap it into the printf
uint32_t ITM_SendChar (uint32_t ch)
{
if (((ITM->TCR & ITM_TCR_ITMENA_Msk) != 0) && /* ITM enabled */
((ITM->TER & 1) != 0) ) /* ITM Port #0 enabled */
{
while (ITM->PORT[0].u32 == 0)
{
__NOP();
}
ITM->PORT[0].u8 = (uint8_t)ch;
}
return (ch);
}
The problem with my configurations was that I didn't have a parser on my computer for the ITM messages so even after having the right configurations on the chip when I was opening the port to communicate with the chip my terminal was empty of messages . Hopefully I found this very helpful parser on github so all I had to do after compiling the program with the above configurations was to run openocd with configuring two options about the frequency of the f1 chip and the
fact that ITM port was open (here is my .cfg file ):
source [find interface/stlink-v2.cfg]
source [find target/stm32f1x.cfg]
init
tpiu config internal - uart off 72000000
itm ports on
and on another terminal I runed the parser script from github python3 swo_parser.py
Related
I tried to communicate with my Arduino Uno using the Boost Asio library. Somehow I can't send data to my Arduino, and I have no idea what i'm doing wrong. Reading works fine, but writing only works when i open a terminal and say:
cat /dev/ttyACM0
When this terminal window is open, and I run my C++ application it works otherwise it doesn't work.
Code of the test application (C++):
#include <iostream>
#include <boost/asio.hpp>
char* message;
int main()
{
boost::asio::io_service ioservice;
boost::asio::serial_port serial(ioservice, "/dev/ttyACM0");
serial.set_option(boost::asio::serial_port_base::baud_rate(115200));
serial.set_option(boost::asio::serial_port::flow_control(boost::asio::serial_port::flow_control::none));
serial.set_option(boost::asio::serial_port::parity(boost::asio::serial_port::parity::none));
serial.set_option(boost::asio::serial_port::stop_bits(boost::asio::serial_port::stop_bits::one));
serial.set_option(boost::asio::serial_port::character_size(boost::asio::serial_port::character_size(8)));
std::string s = "u";
boost::asio::streambuf b;
std::ostream os(&b);
os << s;
boost::asio::write(serial, b.data());
if (serial.is_open()) {
serial.close();
}
return 0;
}
Code of my Arduino application:
#include "Servo.h"
Servo servo;
void setup() {
Serial.begin(115200);
servo.attach(9);
servo.write(0);
}
void loop() {
if(Serial.available()) {
char c = Serial.read();
if(c == 'u') {
servo.write(180);
} else if (c == 'v') {
servo.write(0);
}
}
}
I tried this both on my Ubuntu 18.04 and Debian 10 installation to rule out a permission issue, so I think there is something wrong with my code.
Update:
I found the issue, the Arduino is restarting when making a serial connection. When I add a thread sleep for for example 5 seconds and after that resent the data it works (because then it keeps the serial connection alive). I'm still looking for a permanent solution, so that I don't have to do a write before I really want to write something.
Update 2:
Apparently I don't even have to do a write, but where must be a small delay before I can start writing, because when after opening the port the Arduino is still restarting.
I fixed it with adding a small delay before writing to the serial port. As I also wrote in my comment above, the Arduino is restarting when you start a serial communication.
This can be disabled on several ways: https://playground.arduino.cc/Main/DisablingAutoResetOnSerialConnection/
Another option is to send a "ready" signal from the Arduino to know in your application that the Arduino is rebooted. So then start in your application with reading, and when you received that message, you can start writing.
I'm developing a Windows application that has to communicate (both input and output) with an Arduino through its serial port. I'm using boost::asio for portability reasons and I want to keep using it. What happens is that the first time I run my application it works perfectly, but if I run it a second time, no data comes from the Arduino anymore and the application stucks on the read operation. The only way to recover is to unplug and replug the Arduino USB cable from the computer.
This behavior is Windows-specific. The same code works perfectly on Linux.
The compiler is Visual Studio 2017 Community Edition.
Here is an example code to reproduce the issue:
#include <iostream>
#include <string>
#include <boost/asio.hpp>
#include <vector>
int main() {
boost::asio::serial_port port(ioctx, "COM3"); // "/dev/ttyACM0" on Linux
port.set_option(boost::asio::serial_port::baud_rate(9600));
port.set_option(boost::asio::serial_port::character_size(8));
port.set_option(boost::asio::serial_port::stop_bits(boost::asio::serial_port::stop_bits::one));
port.set_option(boost::asio::serial_port::parity(boost::asio::serial_port::parity::none));
port.set_option(boost::asio::serial_port::flow_control(boost::asio::serial_port::flow_control::none));
char c = 'e';
auto const s = boost::asio::write(port, boost::asio::buffer(&c, 1));
std::cout << "sent " << s << " bytes" << std::endl;
boost::asio::streambuf response;
boost::asio::read_until(port, response, "\r\n");
std::istream response_stream(&response);
std::string line;
std::getline(response_stream, line);
std::cout << line << std::endl;
port.close(); // last-ditch effort to get it working
}
Here is an Arduino sketch (got from the Arduino website):
int incomingByte = 0; // for incoming serial data
void setup() {
Serial.begin(9600); // opens serial port, sets data rate to 9600bps
}
void loop() {
// send data only when you receive data:
if (Serial.available() > 0) {
// read the incoming byte:
incomingByte = Serial.read();
// say what you got:
Serial.print("I received: ");
Serial.println(incomingByte, DEC);
}
}
Is there a way to restore the correct state of the connection? Am I missing something?
After having learned a couple of things, here is the solution:
Arduino uses its USB communication for both burning the sketch and performing data transmission back and forth the PC. The boot sequence foresees that for 2 seconds (for new Arduino versions and standard boot loader) the communication towards the boot loader is active. After that time, the sketch is executed.
Windows API allows to set all connection parameters at once via the SetCommState function and to retrieve them in a similar fashion with the GetCommState one. That is the method the set_option function uses to set the parameters, but it happens that calling GetCommState-SetCommState multiple times in a row slows down the process a lot (maybe by resetting the Arduino multiple times).
I ended writing the following function:
#include <Windows.h>
#include <chrono>
void init_arduino(boost::asio::serial_port& port, std::chrono::milliseconds const& sleep = 2000)
{
DCB dcbSerialParams = { 0 };
GetCommState(port.native_handle(), &dcbSerialParams);
// this is the optimal way to set the whole serial port configuration
// just in one shot.
dcbSerialParams.BaudRate = CBR_9600;
dcbSerialParams.ByteSize = 8;
dcbSerialParams.StopBits = ONESTOPBIT;
dcbSerialParams.Parity = NOPARITY;
//Setting the DTR to Control_Enable ensures that the Arduino is properly
//reset upon establishing a connection
dcbSerialParams.fDtrControl = DTR_CONTROL_ENABLE;
SetCommState(port.native_handle(), &dcbSerialParams);
PurgeComm(port.native_handle(), PURGE_RXCLEAR | PURGE_TXCLEAR);
// Wait for Arduino to boot the sketch
Sleep(sleep.count());
}
and using it to replace the port.set_option( lines in the question example.
I also set the flow control to DTR_CONTROL_ENABLE instead of the original none in order to reset the Arduino upon connection.
USB serial adaptors can have device driver bugs and hardware problems. The fact that you have to unplug and plug the device to get it working again is indicative of a device driver bug.
Look for an updated driver. It will probably a Prolific or FTDI chipset, make sure you get the driver from the chip maker. See Prolific or FTDI
If it is a flow control related hardware problem you can wire together the DTR, DSR and CD pins, and wire together the RTS and CTS pins on the RS-232 connector on the USB adaptor. I have seen USB adaptors where this is necessary, despite setting no flow control in software.
I have recently purchased an Arduino Uno WIFI. It says it already has the ESP8266 wifi module integrated making it WIFI ready. I have successfuly connected to my wifi and wifi console. I have also used the test WebServer Blink test to play around with the pin 13 rest api commands. The problem im having is going beyond this example. I searched for WIFI documentation but can only find this documentation for the WIFI-Shield which is not working for my arduino.
I see in the example they import the #include <ArduinoWiFi.h> but i cannot find this libraries documentation. Is there anyother library I can use with this new arduino wifi? Does anyone have experience with this? I have tried to use the #include <WIFI.h> but it says that I don't have the wifi sheild.
ERROR:
WebServerBlink.ino:14:23: error: 'class ArduinoWifiClass' has no member named 'status'
CODE:
#include <Wire.h>
#include <ArduinoWiFi.h>
/*
on your borwser, you type http://<IP>/arduino/webserver/ or http://<hostname>.local/arduino/webserver/
http://labs.arduino.org/WebServerBlink
*/
void setup() {
pinMode(13,OUTPUT);
Wifi.begin();
Wifi.println("WebServer Server is up");
Wifi.println(Wifi.status()); //Line 14:23:: This will not work
}
void loop() {
while(Wifi.available()){
process(Wifi);
}
delay(50);
}
void process(WifiData client) {
// read the command
String command = client.readStringUntil('/');
// is "digital" command?
if (command == "webserver") {
WebServer(client);
}
if (command == "digital") {
digitalCommand(client);
}
}
void WebServer(WifiData client) {
client.println("HTTP/1.1 200 OK");
client.println("Content-Type: text/html");
client.println();
client.println("<html>");
client.println("<head> </head>");
client.print("<body>");
client.print("Click<input type=button onClick=\"var w=window.open('/arduino/digital/13/1','_parent');w.close();\"value='ON'>pin13 ON<br>");
client.print("Click<input type=button onClick=\"var w=window.open('/arduino/digital/13/0','_parent');w.close();\"value='OFF'>pin13 OFF<br>");
client.print("</body>");
client.println("</html>");
client.print(DELIMITER); // very important to end the communication !!!
}
void digitalCommand(WifiData client) {
int pin, value;
// Read pin number
pin = client.parseInt();
// If the next character is a '/' it means we have an URL
// with a value like: "/digital/13/1"
if (client.read() == '/') {
value = client.parseInt();
digitalWrite(pin, value);
}
// Send feedback to client
client.print(F("Pin D"));
client.print(pin);
client.print(F(" set to "));
client.print(value);
client.print(EOL);
}
There is a big difference between Arduino Uno WIFI (http://www.arduino.org/products/boards/arduino-uno-wifi) from arduino.org and the Arduino WiFi Shield (www.arduino.cc/en/Main/ArduinoWiFiShield) from arduino.cc.
This is a good starting point for your Arduino Uno WIFI:
http://www.arduino.org/learning/getting-started/getting-started-with-arduino-uno-wifi
The next important point is, that you need to use Arduino 1.7 (from arduino.org) especially for OTA programming. Arduino 1.6.x from arduino.cc doesn't work.
Unfortunately they don't really develop their arduinowifi-library well.
I had the same problem on Linux IDE 1.8.1 and I solved it like this:
get https://github.com/arduino-org/Arduino/tree/master/libraries/ArduinoWiFi
add it in .....arduino-1.8.1/libraries/ArduinoWiFi/
restart the IDE. You shall be able to open and run the example sketch under File->Examples->ArduinoWiFi.
I suppose that it will work with any IDE on any platform.
I'm working on a program using RtMidi to communicate with MIDI applications.
Compilation, opening input and output ports, reading input ports works as well, but when I send message with output port, nothing happens.
No exception, no message in terminal, everything seems to be ok, but other apps never receives MIDI message.
$ uname
Linux 3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt7-1 (2015-03-01) x86_64 GNU/Linux
Audio server is ALSA 1.0.28.
$ cat /proc/asound/version
Advanced Linux Sound Architecture Driver Version k3.16.0-4-amd64.
MidiConnection::MidiConnection(QString Name, QObject *Object) : QThread(Object)
{
/*...*/
midiIn = new RtMidiIn(RtMidi::UNSPECIFIED, "Mecanique");
midiIn->openPort(0, Name.toStdString());
midiOut = new RtMidiOut(RtMidi::UNSPECIFIED, "Mecanique");
midiOut->openPort(0, Name.toStdString());
/*...*/
}
void MidiConnection::sendMessage(QVector<unsigned char> message)
{
std::vector<unsigned char> tempVector = message.toStdVector();
midiOut->sendMessage(&tempVector);
}
When I'm testing, tempVector contains right bytes (which are correct about the MIDI specs) (see answer below).
Solution found: this code is absolutely correct, it was the data given to the function sendMessage() which was wrong. When execution start, a value upper than 127 was included in a vector. As result, it seems that ALSA don't listen more the connection without force to close it.
Thanks for your suggestions!
I am using libpcap to sniff traffic. I would like to do it on the currently active network device (e.g. one that has an assigned IP address, etc). What's the best way to do this? I'm assuming I would have to do the following:
pcap_findalldevs(&alldevs, errbuf)
to get all the network devices, then loop through and check which one is currently active.
Edit: The following function
(pcap_lookupnet(dev, &net, &mask, errbuf)
returns the network address and subnet mask for a network device. I ran some tests with the different ethernet adapters on my computer and it returns -1 when I call it on an adapter that is not connected to a network. Would this be the bulletproof way to get an active interface? Are there any edge cases it would miss?
the API pcap has for looking up interfaces conforming to some user defined rules is trivial. You could indeed use pcap_findalldevs() to interate over all suitable-to-use network devices or use pcap_lookupdev() to get the next network device that you can use with pcap. Defining what is the interface you want to use with your sniffer may be problematic (code wise) on systems with multiple network devices and you would want to define more explicit rules for choosing such an interface. Such rules are usually statically defined (like "the active interface with the default route installed"). However, you may have multiple default routes (think load balancing) and here you may either want to sniff on all of them or (for example) only on the ppp interface. So choosing the target interface I would say is a task to be resolved outside the sniffer rather than at runtime in the sniffer code.
For example:
If by "active interface" we understand the interface on which the default route is installed (i assume a linux system here):
ip route show 0.0.0.0/0 | awk ' { print $5 ; } ' | xargs ./sniffer
if you want to get the active interface which has the default route installed on from your sniffer code, you would rather use netlink(7) or proc(5) (/proc/net/route) than pcap's device lookup api but the complexity is high.
In conclusion, the interface lookup logic can be easily scripted into some wrapper program on any system and the result(s) passed as parameter(s) to your sniffer.
Why don't you capture on 'any' device (Pseudo-device that captures on all interfaces) ?
Any way, here is a little snippet that will help you find 'active' interfaces
#include <stdio.h>
#include <pcap.h>
#include <sys/socket.h>
#include <netinet/in.h>
#include <arpa/inet.h>
static void
dump_addresses (pcap_addr_t *addresses)
{
pcap_addr_t *addr = addresses;
printf("(");
while (addr) {
struct sockaddr_in *ip = (struct sockaddr_in *)addr->addr;
struct sockaddr_in *nm = (struct sockaddr_in *)addr->netmask;
if (ip && nm)
printf("%s/%s ",
inet_ntoa(ip->sin_addr), inet_ntoa(nm->sin_addr));
addr = addr->next;
}
printf(")");
}
static void
devs_dump (pcap_if_t *devs)
{
pcap_if_t *dev = devs;
while (dev) {
printf("dev: %s - %s - ",
dev->name, dev->description);
dump_addresses(dev->addresses);
printf("\n");
dev = dev->next;
}
}
int
main(int argc, char *argv[])
{
int r;
char errbuf[PCAP_ERRBUF_SIZE];
pcap_if_t *devs;
r = pcap_findalldevs (&devs, errbuf);
if (r) {
printf("Findalldevs: %d (%s)\n", r, errbuf);
return -1;
}
devs_dump(devs);
pcap_freealldevs (devs);
return 0;
}
I've been down this road several times before, and usually find myself falling back to adding a -i switch to allow the user to precisely identify the interface.
It makes your job simpler and avoids any edge conditions.
According to pcap_open_live (3):
DESCRIPTION
pcap_open_live() is used to obtain a packet capture handle to
look at packets on the network. device is a string that
specifies the network device to open; on Linux systems with
2.2 or later kernels, a device argument of "any" or NULL can
be used to capture packets from all interfaces.
But it seems it's deprecated now, you should use pcap_create(3)