We managed to hookup our hardware by following suggested design, and we wanted to use only CAN protocol. And on the breadboard with STN1110 DIP package everything works great on ECUSim 2000 simulator and on a actual car. BUT, when we designed a PCB and moved to QFN, we are getting weird messages from STN1110 chip.

For example, we have the same test environment for breadboard and for actual PCB, but for that PCB we just ended up with these messages from Torque "Identifying ECU" and "Check if ignition is on" (and it is on). With breadboard everything is fine, we are getting our readings.

Also, if we put on a side Torque, and if we try to communicate directly with STN1110, if we send for example ATZ, we are getting response valid response. But if we try to run for example some command, let's say 0902 we are getting from PCB when we run the command via FTDI: BUS INIT STOPPED BUS INIT FB ERROR (this is from PCB (QFN version of STN1110))

And we triple checked PCB design and all the traces between STN1110 and MCP2551 and MCP2551 and a simulator \ car, and everything is fine, we even replaced MCP2551 just in case but same error.

Any suggestion what else we can try?

  • 1
    \$\begingroup\$ First things first, post a schematic. \$\endgroup\$ Sep 3, 2016 at 16:19
  • \$\begingroup\$ How about 09 02 5 command? \$\endgroup\$ Sep 3, 2016 at 16:48
  • \$\begingroup\$ @Tony I tried 0902 on a breadboard, and I'm getting valid byte array but not from PCB. From PCB I'm getting BUS INIT STOPPED and BUS INIT FB ERROR. \$\endgroup\$
    – ShP
    Sep 4, 2016 at 0:53
  • 1
    \$\begingroup\$ Yes, different cabling is the first thing that @TonyStewart mentioned in his answer. You should really have said this in your question, otherwise it sounds like the only difference is the breadboard vs PCB. \$\endgroup\$ Sep 4, 2016 at 4:44
  • 1
    \$\begingroup\$ I'm voting to close this question as off-topic because missing information. \$\endgroup\$ Sep 8, 2019 at 12:43

1 Answer 1


Is it possible you have a difference in the method of grounding and cabling, such that there may be more Analog ground noise or Common Mode noise on cables?

DFT would warrant some method of loopback testing for analog output and inout signals with a test set and I am it not sure what capacity your simulation box has.

It may be tedious, but examining or simulating the signal source through your cables and verify the destination at the chip using high speed diff. probes might prove useful to check the input response and noise levels.

Use a logic analyzer or terminal in parallel with control characters visible and examine the results. If signal integrity is ok, look for invalid control bytes on the serial port. Using a diode OR with 10k to ground for RX @ TX , I used to display both on a single monitor to examine traffic in parallel. RS232 threshold is 1.3V.

Does AT@1 or at@2 give any Results? (not case sensitive)

Testability is a key part of the design phase often overlooked with hopeful results.

  • \$\begingroup\$ Yes, I'm getting valid result for AT commands. So UART communication with STN chip seams to be ok. But when I try to run something like 0902 for example or any other similar command to get a data from a car (and both car and simulator support this command) I'm getting that message: BUS INIT STOPPED, and BUS INIT FB ERROR. \$\endgroup\$
    – ShP
    Sep 4, 2016 at 0:47
  • \$\begingroup\$ you are right, I do have different way of grounding and cabling. I also have longer cable on PCB vs breadboard which goes to OBD adapter (and it's not twisted pair also). PCB cable is around 50cm, vs breadboard cable which is around 25cm. And of course I have different trace for GDN. What would be your suggestion on this? I'm still el. newbie and I don't have some fancy equipment for testing. \$\endgroup\$
    – ShP
    Sep 4, 2016 at 4:47

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.