1

I have tried various Nodemcu builds based on the idf 4 (including the online builder) and cannot get the CAN bus to work on the built-in CAN controller. When I do make menuconfig, I don't see anything about the CAN module except the TWAI configuration. I believe that the module is included in the build by default, but perhaps this is not the case. Thanks for any advice!

local can = require("can") --just for test
can.setup({
  speed = 500,
  tx = 5,
  rx = 4,
  dual_filter = false,
  code = 0,
  mask = 0xffffffff
}, function(format, msg_id, data)
     print(format, msg_id, data)
end)

sendTimer = tmr.create()
sendTimer:register(1000, tmr.ALARM_AUTO, function() 

can.send(can.STANDARD_FRAME, 0x123, "a");
print('send...')

end)

can.start()
sendTimer:start()

Tryin send and recieve CAN message, but this not working Some of my builds give the message that CAN not not defined (can.lua:2: attempt to index a nil value (field 'can') ), and build from online service (where does kan end up in the list of modules) give the effect:

  1. transmitted message from another device i see in CAN sniffer, but in my code callback no calling.
  2. When a try send message every 1000 ms I don't see any activity to the TX pin on ESP32 (measure oscilloscope to)
hofmaker
  • 11
  • 3
  • Please edit the question to be clear about what “not working” means. Does it crash? Do you get error messages (in that case what are they?)? Does it hang? Your code is only trying to send a message so what is it that you expect to see if it works? – romkey Mar 03 '23 at 16:33
  • 1
    @romkey, tnx. I am edit my post – hofmaker Mar 03 '23 at 17:22
  • Thanks, that's much more helpful :) – romkey Mar 04 '23 at 02:17

1 Answers1

0

As it turned out, the CAN controller in ESP32 is quite specific. There is some mention in espidf:

An external transceiver must internally tie the TX input and the RX output such that a change in logic level to the TX signal line can be observed on the RX line. Failing to do so will cause the CAN controller to interpret differences in logic levels between the two signal lines as a lost in arbitration or a bit error.

I managed to establish an exchange first between 2 and then 3 devices, but by connecting another one that differs only in the revision of the chip (judging by the debugging information, devices that work successfully have chip rev3, and the device that ultimately caused the bus to fall has chip rev1). I could not find any regularities regarding the revision of the chip in the documentation or errata.

hofmaker
  • 11
  • 3