My first question on here so I'm not sure if that's the right forum.
I've connected with my car's ECU K-Line through FTDI-OBD cable and terminal. Found it's something like KWP2000 but without preinit hassle. I just send it commands on 9600 baud, even parity, 1 bit stop and got a reply with VIN number. When I try to send same command with ELM327 it doesn't work and I believe because of ELM adding something, either initialisation of the KWP or adding some checksum or additional info and it doesn't work.
I've already tried using
ATSP5
ATIB96
ATBI
And it still doesn't respond eg. VIN message from sending same command.
My point is to get to secret sensors data from $21 because there is a little info in regular Mode01. And I want to use ELM327 because I wanted to use Android phone to display the data.
Related
I am trying to make some custom firmware for a MIDI controller (AKAI LPD8).
There is an STM32F102R8T6 chip in the unit.
I am trying to reach it with a programmer to wipe it, but it seems to not be responsive.
Some information and thing I have tried:
The firmware that came with the unit works, so the chip is not broken
Removed the components connected to the programming pins (PA9-PA10 and PA13-PA14)
I am able to pull BOOT0 high and have it not run the main program, but I am however not able to get a life sign using either an ST-Link2(clone) connected to PA13/14, nor a USB to serial adapter connected to PA9/PA10, so I am not sure what mode it is in
The connection has been checked, and RX-TX etc is the correct way around (but also for the sake of trying it all, I reversed the connections as well...).
Tried both the STM32CubeProgrammer and stm32flash, but none connects.
I am actually not sure if AKAI have locked the chip in such a way that you cannot even do a full chip erase and use the chip for something new? The NRST pin is strangely not doing anything to the running of the firmware either when I try to pull it low.
Is there a way to reprogram these chips when they come off of a commercial product, or are they permanently locked?
Any solution/tips?
Many of the STM32 parts have "proprietary code read-out protection" (google PCROP) which but you might be lucky and they haven't enabled it in the option bytes. Read the documentation for that and the bootloader documentation and get a good idea of what you expect it to do if it is enabled and if it isn't.
If you have a scope, try watching the SWD/JTAG pins to see if there is any response from the device. (If you aren't even sure if it is in reset then scope the crystal if there is one).
If you haven't got a scope, you might be able to to verify what it is doing by seeing if it sets the pins and pull-resistors to how they would be expected to be in the bootloader mode, eg: UART TX should be high if it is enabled, even it it isn't transmitting anything. Put a strong pull-down (~1k) on there and see if it still reads high.
After hours of trying different ways of making it work (also tried the alternate mapping of the UART port), and probed the TX pin as suggested by Tom V to no avail, I have given up working on that specific chip and ordered an upgrade from the STM32F4 family instead to replace it with. A lot more power and useful peripherals.
A bit of a non-answer to the specific question. Frustrating to not have found out what was wrong (chip or approach) but being mindful of the sunk cost fallacy, I think it was best to just replace the chip with a fresh one and start development from there.
I'm trying to get a Raspberry Pi with a 4" touch screen setup to wardrive and capture some WiFi signals. The piece that is giving me issues is getting the GPS working.
I'm trying to use a module that came with Microsoft Streets & Trips I got a long time ago.
lsusb shows the device as "Bus 001 Device 007: ID 1546:01a5 U-Blox AG [u-blox 5]"
dmesg | grep tty shows:
[ 8.276615] cdc_acm 1-1.1:1.0: ttyACM0: USB ACM device
[ 344.931792] cdc_acm 1-1.1:1.0: ttyACM0: USB ACM device
I do see a data stream if I issue cat /dev/ttyACM0
sudo gpsd /dev/ttyACM0 -F /var/run/gpsd.sock and then gpsmon /dev/ttyACM0 gives the following:
But then when I try cgps -s I get:
I seem to be getting some data but no lat/long/time data.
Should I conclude that this GPS module is not supported?
Are you sure your receiver has a satellite fix? Also, you have a log of the GPS data stream? Do you know what specific model receiver you are using?
From your first screenshot it looks like you are definitely receiving data from the GPS, as it's recognizing several different NMEA sentences. On top of that, the first screenshot shows what seems to be a valid GPGLL sentence (I haven't confirmed the checksum):
$GPGLL,,,,,224538.00,V,N*40
My initial hunch would be that the GPS receiver does not have a satellite fix. This is based on
Empty GPGLL sentence. The only populated fields in the above sentence are the UTC time and Status fields. The Status value is V, which means the data is invalid.
Status NO FIX in the second screenshot.
The various boxes in the first screenshot give me the impression that GPSD is correctly parsing the various NMEA packets. For example, the GSV box lists various satellites in view.
The lsusb output reports the device as a u-blox receiver. U-blox receivers generally have solid support from GPSD, so I'd be surprised if this receiver isn't supported (but anything is possible). Without knowing the specific model it's hard to say anything definitive.
I've only worked with a couple different receivers, but my general experience is that when they don't have a fix on startup they'll send empty/partial packets. And the date/time data in those packets is probably due to a Real-time clock (RTC) on the receiver. RTCs are common on GPS receivers as they often drastically improve the Time To First Fix (TTFF). So it makes sense that you have a time, but it's marked as invalid.
Recommendations
The fact that your receiver is reporting satellites in view (though none are being used) and that the Status is NO FIX is especially strong evidence to me that your receiver probably just doesn't have a fix. Try moving it to somewhere with a better view of the sky. Also ensure that if it requires any kind of external antenna hardware that you connect that. Lastly, you might have to wait awhile to get a fix. If it's been awhile since you've used the device you could be looking at a cold start with a TTFF of upwards of 10-20 minutes.
I am using stm32f4 on discovery board with freertos running on it.
Just started working with stm32 controller and trying to make data transfer using UART. Printf based on HAL_UART_Transmit works perfectly, but receiving data isn't working.
According to numerous tutorials it should be very simple. I create a project in Stm32CubeMX, add all necessary stuff (freertos, USART3, NVIC), enable USART3 global interrupt and generate the code.
I'm trying to add HAL_UART_Receive_IT(&huart3, &rx_char, 1); or something similar in a task and it doesn't do anything. I suppose it flies through it very fast and doesn't wait for characters to be sent from the terminal.
What do I miss here?
I try to find library which may make a call from mobile phone and receive status of answer(answered, busy, missed etc.) Mobile phone will be Nokia 6300 or any other which will more optimal for this target. Phone will be connected through USB. The ideal solution - is cross-platform library (but distribution platform will Windows). I glad to get any suggestions how to solve my goal including sending AT commands.
Thank you!
I assume you are talking about voice calls, right? For just the basic functionality you can look at the response from ATD and use atinout, e.g.
C:\>echo ATD123456890; | atinout - COM14 -
OK
C:\>
for a successfully answered call, and with BUSY instead of OK for a busy call, and not answered I think will return NO CARRIER.
Now, I have not tested atinout with a modem on windows, so I do not know how well this works, but I know it compiles fine with both cygwin and mingw, but the cygwin compiled binary seems not to be able to open a com-port properly, so try first compiling with mingw. By all means report success/failure on this.
For additional call progress information, I think there is some newer command specified in the latest versions of 27.007 for this which is unlikely supported by your phones, but AT+CIND is probably supported and you might also get some useful information from AT+COLP and similar commands.
Try to play with at+clcc.
Currently this is only command I could find to detect whether call was initiated.
It returns complex string: "1,0,2,.....", so you should start timer task and track third digit: 2 - init the call, 0 - call dropped, 3 - wait signal received (ringing).
check this help http://www.activexperts.com/serial-port-component/tutorials/gsmdial/
I'm trying to use the lpc1343 as a i2cslave to transmit some data. Writing to the board gives no problems and works exactly as I want it.
However, reading from the board gives problems. It seems I'm not getting any data back although I am sending the right commands. Whenever I try to debug it my board just hangs and I have to reset the driver and my pc to get it running again.
Also, I made a LED go on/off whenever I try to read from it. It only does this once and whenever I try to do it again nothing happens. I think the I2c is stopped then but I have no idea why.
I have found the example code on the website once but now it seems to be gone. Does somebody have an updated I2cslave code?
Which operating system are you writing code for and how can you tell that writing to the i2c chip is successful?
If the write function returns, it could be that the message has been sent but the chip is in a weird configuration that doesn't act on the message received.