Project Logs

Collapse

• Have Hammer, Will Hack

  darkspr1te • 05/24/2018 at 18:10 • 0 comments

  Ok, so I left off last time telling you about the default aspect of the STM32F to have the debug pins high and that on our device they are tied into two parts of the system, namely CAN bus and K-Line in some way. Well we had already lifted PIN8 of the CAN chip to enable us to talk back to can devices, this is in fact thanks to the great HardwareCAN lib on the arduino STM32 forums, with just a few tweaks it was working (once we figured out the board mechanics)  but we didnt want to lift all the none working pads or pads tied into the debug system or other parts, so along comes gpio remapping of debug pins and once triggered to one map will stay like that until reset so if you do something silly like us and put that call in the setup() then you're asking for trouble and head scratching. Did I mention I know nothing about STM's until this project, all my prior STM troubles were STM8 based, 

  So after i finished my small angry dance I looked back at the data sheets, to my pleasure there are two boot control pins, BOOT0 & BOOT1, between them they control the boot order like your bios does except this is raw board level stuff that only louis talks about.  

  So we have a way to get back in as I am not fast enough to catch the reset and trigger the STLINK before it runs my debug disable code, oh, that points to a design choice, did they use the debug pins on purpose ? anyway back to the story, So looking at the board we see PIN60/BOOT0 tied to GND via a resistor R17, so if we put 3.3v to the PIN side of the resistor and reset the STM32F then we boot to system memory, if this is done after power up there is no code there so we can let go of our probes and send the new firmware without debug disable included, or at least a way to reactivate it, that is why the git code now has a pause to display clock speeds,can status, eeprom status. that is not to impress but allow me time to reflash without having to use boot0/boot1 pins, oh BOOT1 is PB2 connected to R7 and on to GND. 

  Ok, we are back onto working device, 

  And thats where we are currently, The next steps are doing a better menu system to speed up testing the OBD code in the field, right now it's a jumble of test code and silly remarks. 

  Next weeks episode, Of course Captain  I can give you more 

• CAN We do it? yes we CAN

  darkspr1te • 05/24/2018 at 17:46 • 0 comments

  So lets talk a bit about the CAN side, The can chip is a NXP TJA1050 SO8 , quite simple pin out, apart from usual power there is can High/LOW, TX & RX and mute , oh one other is voltage ref out but thats not a function concern as were are not designing the system, just using it. So we have 5 pins for it's operation, our uarts TX & RX which is the low side or MCU side and CAN High/Low which is vehicle side or hot side (Pin 6 & 15 OBD)

  Last pin of the can chip is the mute control, this is to stop devices putting noise on the system when starting up, you have this pin tied to 3.3v via a resistor and it will mute the chip at power on until your MCU bring it low for comms, in this case our STM32F103's SWD pin PA13 is tied to the Mute control and during normal debugging PA13 is always high, Now of course we did not know this and proceeded to lift PIN8 (Silent) and connect it to a unused pin PA8, which on different devices connect to a transistor, resistor and finally a little speaker. In our board photo's you will see I've hijacked PA8 to be my CAN mute control and my PIN13 led, I'am not bothed about introducing some random characters just yet so pin is not tied high but goes via a resistor and led to 3.3v, so when led is on I am TX'ing although you will notic i dont shut it off that often in the source code, We still have to tidy up a lot of functions to become usable, in fact this may be reworked into a new app totaly and only use part of the code, the original github om127-reboot was to get the board going, a final application for the device might be a start from scratch now that we know what 'ahem' we are doing. 

  Did i mention that annoying bit about PA13 being high all the time, "cue afroman" , well the cure is to issue 

  afio_cfg_debug_ports(AFIO_DEBUG_NONE);

   But a word of warning here, one the above has been called then you cannot reflash using stmlink without doing some other things first,

  You can reactivate the STLINK/SWD port on pins PA13/PA15 buy calling the following ,

  afio_cfg_debug_ports(AFIO_DEBUG_FULL_SWJ);

  also indecently , calling  

  afio_cfg_debug_ports(AFIO_DEBUG_SW_ONLY);

  will keep PA13 as SWD and allow the STLINK to trigger debug, this switches PA15 back to SWDCLK from being a gpio which DEBUG_NONE or DEBUG_FULL_SWJ will trigger.

  So what have we learned kids ? 

  yes thats right, I locked myself out of my STM32F,

  ah well, stay tuned for tomorrow's new school old project, bReaking bAck 

  darkspr1te

• Reversing Gear

  darkspr1te • 05/24/2018 at 16:04 • 0 comments

  Ok, so we have a quick overview of the device, now what. Well that was the hard and fun part, I started with some overhead board shots from my mate 8 and using gimp I traced out all the pins to the first via or component, along with a underside board shot i would trace them to the next point, My main goal was to get to the first big device on each pin, a example would be the TX pin (PA9) , it's first device was a transistor, Ok so this circuit could be a buffer or voltage converter as it has two NPN transistors in series (Q4/Q5) which goes onto pin 7 of the OBD, that K line TX, Then we traced RX into that same circuit via U7 , U7 is a comparitor,   one side of U7 is conected to the K-Line and the other is J1850 bus, My assumption is it's for RX'ing the Differential signals and sending them to the RX of the hardware & software UARTS, the other side of the transistors (Source ) is connected to the 12V+ from the vehicle via a few resistors. 

  So now we know that out K-line setup is two transistors in series and a few resistors to 12V, a big o google later and i found that ELM uses that setup for the 327 model chip, see

  KL-Line ELM327
  

  It does not have the LM393 there but a few other OBD readers do and all point to the other side of the differential signal and as a buffer, as it's connect to the OUT1 of LM393 then thats a good bet ,

   it's shown in this schematic LM393 in differential RX circuit

  Next we shall look at the CAN BUS and J1850+ parts in more depth

• Nice Hardware , Let's interface

  darkspr1te • 05/24/2018 at 10:55 • 0 comments

  So Lets talk about the hardware more a little, 

  The Board has the following Main IC's on one side,

  U1: STM32F103RC8

  U2: Winbond w25q64f

  U6: NXP/Phillips TJA1050

  U7: LM393 comparator

  LCD: -

  Chip Type: ST7565 

  Model Type: ERC12864 

  Pixels:128 x 64

  u8g2 header:- U8G2_ST7565_ERC12864_1_4W_SW_SPI

  
  

  Well that's the gold doubloon's, now for some pieces of eight, well that comes as assorted 1AM NPN and 2A PNP transistors that provide the K-L Line and J1850 Bus ,

  The K-Kline is made up of 3 pins, TX, RX and Inverted Bus Pin, This uses the SWDCLK pin and hardware UART.

  The J1850 Bus is a Differential bus and uses software uart of the STM32, 

  full reversing of this is yet to be done, 

  Well, more logs to come but it's time to run.

• The Hardware

  darkspr1te • 05/24/2018 at 10:16 • 0 comments

  So as we can see from the prior read me information we have a lot of the board functioning in a basic way.

  Q:So why do this?

  A: We have a perfectly working device apart from firmware, Also i've been wanting to dig into canbus etc for a while and this seemed like a good way by mistake of course.

  So hardware wise it will be doing what it was designed for, reading cars obd ports to get codes, delete codes and report information. Now a quick browse of the various providers of OBD tools you get massive ones like snapon that do the kitchen sink to ELM devices that act as gateway for pc software.

  Always carrying a pc with when i had rare chance to investigate a cars obd seemed as daft as the drunken sailor taking a nature moment at the end of the plank And no buried treasure to buy the Snapon tools. 

  The OM127 is a fit in the moddle with easy to read screen and BUS power as well as all the needed "bits" to access most OBD systems, whats missing is the decent software. In the short time i used the original software I found it limited, this may be by design to use K.I.S.S standards, many mechanics shy away from the dreaded 12V+ words and the other nasties like CAN 'who' BUS ,hmm, that sounds like a Egyptian god, a quick google later it seems not, Anubis is closest. Is it because it's ment to be cheap and basic in the function department so they can sell another bigger model, well to be honest it's normal practice for the latter, sell other model's with other features off one hardware platform, I will also come back to this as sometimes that one hardware platform changes but yet is still the same. 

  Anyway, Back OT, 

  Thanks to a few great OSS projects like u8x8/u8g2 , winbond spi for stm32, STM32duino , HardwareCAN lib also  from the stm32 duino forums I have got a device that can sniff CAN and save to eeprom , it also displays the sniffed CAN signals.

  Most of the code is test code to bring up the various parts of the original hardware, Thats LCD, Buttons, USB, CAN, K/L-Line/SAE , SPI (EEPROM) .

  Most of the time was spent building a idea of how the hardware was tied together, what problems did the designers have (Like the C128's bus wire to eliminate a reflection) , did they fix it or ignore it or fix it in software ?

  I'll fill you in on those choices/idea/theories in the net log update.  

• Bring 'yer Boards up 'matey

  darkspr1te • 05/24/2018 at 09:55 • 0 comments

  This is the Readme as of May 24, 2018

  Basic board bring up, CAN 500 working, LCD working, Buttons (polling) Working, UART1 Serial Working, USB/USB Detect working. Partial REV ENG of schematics,

  ```
  CPU:STM32F103RB 
  CAN IC:TJA1050
  K-Line : Transistor/Opamp
  ```

  ### Still TODO:

  - [o] Add more CAN OBD logic,
  - [x] remap SWD to GPIO for CAN chip mute control
  - [x] rev eng K-line etc (Prob similar to ELM327 schematics)
  - [o] Add protocols for :-
    - [ ] 1 SAE J1850 PWM (41.6 kbaud)
    - [ ] 2 SAE J1850 VPW (10.4 kbaud)
    - [o] 3 ISO 9141-2 (5 baud init, 10.4 kbaud)
    - [o] 4 ISO 14230-4 KWP (5 baud init, 10.4 kbaud)
    - [o] 5 ISO 14230-4 KWP (fast init, 10.4 kbaud)
    - [o] 6 ISO 15765-4 CAN (11 bit ID, 500 kbaud)
    - [ ] 7 ISO 15765-4 CAN (29 bit ID, 500 kbaud)
    - [o] 8 ISO 15765-4 CAN (11 bit ID, 250 kbaud) - used mainly on utility vehicles and Volvo
    - [ ] 9 ISO 15765-4 CAN (29 bit ID, 250 kbaud) - used mainly on utility vehicles and Volvo
  - [x] EEPROM not working, SPI still needs work :- FIXED

  x = working but not necessarily feature rich
  o = implemented but not necessarily working correctly 

  Device URL :- http://www.autophix.com/en/obd-mate/om127.html

  ---

  Requires modified Arduino STM32F1x see [this](http://www.stm32duino.com/viewtopic.php?t=72)

  also see:
  `rogerclarkmelbourne/Arduino_STM32@master...coddingtonbear:HardwareCAN`

  also [SPI flash lib](http://www.stm32duino.com/viewtopic.php?t=9)

  Device [URL](http://www.autophix.com/en/obd-mate/om127.html)

  `PA13` is shared with CAN Mute & SWD, lift leg and leave floating for CANBUS `TX Enable` or add a jumper wire from solder point next to `R18` to `PIN8` of the **TJA1050** SO8 chip, leg must be lifted from pad to allow control (`PA13 `is always *high* when remapped for SWD)

  Will be adding K-Line soon

  https://github.com/iwanders/OBD9141

View all 6 project logs