I cannot find a comprehensive guide on how to build a Synthetic LIN Slave in a CANoe configuration, so I would like to create one here.
Scenario: an ECU acts as LIN master and communicates with n LIN slaves. The goal is to be able to add a synthetic slave to the CANoe simulation acting as a replacer for one of the physical slaves. Since there is no way to dynamically activate or de-activate a LIN node, our setup would be of n-1 physical slaves and 1 synthetic slave, plus the Master. Here, Master is under test, and, in particular, we want to assess its ability to react to certain slave responses, by mocking the slave and triggering whatever frame is needed. Let's assume there will be a GUI or something for that, it is not in scope for the question.
I am able to add a new Node to the simulation setup, assign it to the LIN network and, if active, it connects to the red line indicating the simulated bus. An LDF was created and added to the configuration and I know the linFrame ID the node should communicate.
The node is to be simulated via CAPL script. I am stuck on the transmission part:
on ???
{
// This is my call: as LIN slave I should output something.
output(myLinFrame);
}
Where should I add my logic to update and transmit the message?
The basic I tried was to key-bind it, but the output would be on the next associated slot of the LDF, plus it's key-bound.
on key 'A'
{
// prepare new content...
output(myLinFrame);
}
This question relates to an older question of mine regarding LIN censorship.
Final note: I have very limited slots for CANoe licenses to test whatever code I come up with, so I need to prepare and research in advance.
In this scenario, should I use linUpdateResponse()?
You should create on linFrame ... event handlers.
These event handlers will be called, once a frame has been put to the bus.
Inside the event handler, you can use linUpdateResponse (or also output) to modify the frame which will be sent the next time, i.e. the call modifies does not send an immediate response but rather modifies the internal state of the slave so that a different frame is sent next time.
Related
Assume there are two boards with stm32 micro-controllers which are connected to each other with rs-485 (each board has a uart-to-rs485 transceiver). This is the connection diagram and the accessible ports:
I want to be able to re-program each board separately using rs-485 wires that are available. Using st system bootloader and boot0 pin is not an option because it requires changing the PCB and re-wiring the system.
So I need to write my own custom bootloader. What I intend to do is to separate the flash memory of the B-1 MCU into three parts:
20KB for bootloader
120KB for B-2 application (as kind of a buffer)
360KB for B-1 application (bootloader jumps to this part after finishing boot mode)
and for B-2, two partitions:
20KB for bootloader
100KB for main application
and using the UART interface of B-1, I can load the .hex files to the specified flash area and tell the MCU what to do with it (either use it as it's own main app or send it to B-2).
Here is a brief algorithm for the bootloader:
// B1: starts from bootloader
for (5 seconds) {
// check for the boot command from UART
if (command received) {
// send boot and reset command to B-2 and receive ack
// start the boot mode
while (boot mode not aborted) {
// receive command packet containing address
if (command == header && address == B1) {
// prompt for the main .hex file and store it in B-1 partition
} else if (command == header && address == B2) {
// prompt for the main .hex file and store it in B-2 partition
// send header and the app to B-2 using rs-485 port
} else if (command == abort) {
break from while loop
}
}
} else {
// do nothing
}
}
// jump to main application
Now I have 2 concerns:
Since there is no gpio connection between B-1 and B-2 to activate boot mode for B-2, is it possible for B-2 board to set a flag in flash memory outside of it's main application area to check for it and use it as a boot mode activation flag?
Is it possible to write the stream of data directly from uart input to the flash memory area of each application? like this:
// Obviously this address is outside the flash area of the current bootloader running
uint8_t appAddress = B2_APP_FLASH_MEMORY_PARTITION_START_ADDRESS;
for (i from 0 to size_of_app) {
hal_uart_receive(&uartPort, appAddress + i, 1, timeout);
}
Since there is no gpio connection between B-1 and B-2 to activate boot mode for B-2, is it possible for B-2 board to set a flag in flash memory outside of it's main application area to check for it and use it as a boot mode activation flag?
I am not sure that you are suggesting, or how your suggestion will solve the problem. Ideally you would have a means form B1 of directly resetting B2 via its /RESET line, but failing that if it is loaded with an application that accepts a reset command or signal over the RS-485, then you can then have it issue a soft-reset to start the bootloader. On Cortex-M devices you can do that through the NVIC.
If you need to communicate information to the B2 bootloader - perhaps to either invoke an update or to bypass that and boot the application, you need not program flash memory for that, you can simply write a boot command or signature via a reserved area of SRAM (best right at the top) that is not initialised by the runtime start-up (or the content of which you capture before such initialisation). Content in SRAM will survive a reset so long as power is maintained, so it can be used to communicate between the application and the bootloader - both ways.
This is of course a bootstrap issue - what if there is no application loaded to accept a reset command, or the application is not valid/complete (programming interruption). Well the relocated application area will have its vector table including its initial-SP and reset vector right at the start. In your bootloader when the first 8 bytes of the image are received, you hold them back and do not program that area until the rest of the image is written. By programming the reset vector last, if the programming is interrupted, that location will not be a valid address. The bootloader can validate it (or check if it is in the erase state) and if not valid/written, it can wait indefinitely for an update or simply reset to repeat the update polling. Be aware of a bit of an STM32 gotcha here though - most parts erase flash to "all-ones" (0xFF) state, some however (STM32Lxx parts) erase to "all-zeroes". Of course you couls simply check for 0x00000000 or 0xffffffff since neither would be a valid start address, or explicitly check the range.
Is it possible to write the stream of data directly from uart input to the flash memory area of each application? like this:
Yes, but remember that on STM32, normally the code is executing from the same flash memory you are trying to program and that the bus stalls during flash write and erase, such that if you are executing from flash, execution halts. For page erase, that can be several milliseconds - for parts with large pages, several hundred milliseconds even. That may mean that you fail to read characters on the UART if you are using polling or interrupt.
You can overcome this issue by protocol design. For example if you use a packet protocol where the last packet must be acknowledged before the next one is sent, you can use that as a flow control. Once you have collated a block of data to be written, you simply delay the acknowledgement of the last packet until after you have erased and/or written the data to flash. XMODEM-1K is a suitable protocol for that and despite its flaws its simplicity and support in common terminal emulator applications make it a good choice for this application.
Now all that said, you can increase the flash available to B1 by not buffering the image for B2 on B1 at all and simply implement a bi-directional pass-through such that the input on the UART of B1 is passed directly to the B1 RS-485 output, (surely also a UART so your port naming is ambiguous), and B1 RS-485 input passed directly to the UART output. That way B1 becomes "transparent" and the update tool will appear to be communicating directly with B2. That is perhaps far simpler and faster, and if the bootloader is "fail-safe" as described above, will still allow retries following interruption.
The pass-through function might be part of B1's application or a "mode" of the bootloader. The pass-through mode might be invoked by a particular boot command or you might have the application pass a "boot mode" command via the SRAM mechanism described earlier.
In either case ideally you would have identical bootloader code on both B1 and B2 for simplicity and flexibility. There is no reason why that should not be the case; they are both receiving the updates over UART.
I'm struggling to understand how timed games work together with (broadcast) synchronization in UPPAAL (TiGa / Stratego). Imagine the following example:
Forcing the environment
Here, the edge receiving an event over the broadcast channel a is controlled by the environment. From what I understand, the semantics of broadcast synchronization enforce a transition in P2 from the initial state to P2.F as soon as the event is sent in P1 (assuming edge P2.<init> -> P2.F is enabled).
So naturally I would expect a strategy to exist for the controller to force the environment to transition to P2.F. This strategy would simply tell the controller to take the transition P1.<init> -> P1.F.
However, when calling the query control: A<> P2.F, UPPAL TiGa and Stratego tell me that there is no such strategy and that the counter-strategy for the environment is to stay in P2.<init> is simply wait forever.
Being forced by the environment:
When controller and environment switch sides, it looks a little different.
In that case, the query control: A[] (not P2.F) is not satisfied, indicating that there is no chance for the controller to prevent the environment from forcing a transition to P2.F.
In both examples A[] P1.F imply P2.F and E<> P1.F hold.
I'm curious about why the environment seems to be able to evade a transition that a controller can't, or if anyone can point me to some place where the timed game semantics of UPPAAL TiGa or Stratego are explained in detail.
Thank you all!
I have 2 nodes (x and y) on a can bus using canopen. Using a temp node "z" I send an nmt message to put all nodes in preop state and then a command to put y into operational state. I then send a bunch of extended id messages on the bus intended for node y, node x does not know of these in its dictionary. During the sending to y, node monitoring on node x says it is in preop state. All seems fine. Upon completing of sending data to node y I send a command to put all nodes into operational state. Node x is stuck in preop state according to its nmt state code. Debugging i found the rx fifo in canopen x is overflowing. It should be ignoring all these extended messages when in preop mode? I even tried in stopped mode with the same results of a stuck x. Whats going on here?
For any CAN bus node, you have to read all incoming messages continuously and ignore the ones of no interest. Filter settings in the CAN controller can help a bit, but to build rugged applications, you must always be prepared that any CAN message with any ID can appear at any time. The best way to ensure this is to always read rx fifo buffer continuously, and at each time keep reading until it is empty.
A CANopen node remains in pre-operational state as long as there are errors. Optionally, it may send out an EMCY message telling the nature of the error, and then another with all bits set to zero when the error is cleared. In which case the NMT master should wait until EMCY clear message, before sending out start remote node.
I have an existing embedded system with an existing developed C code.
Sometimes the microSD card can lock down giving responses outside of the scope of the existing system.
I'm currently unsure why but suspect the handler in the existing system allows subsequent calls to be made too quickly.
The card is being used in Spi mode to have direct I/O.
The circuit diagram does not show any control over the power to and from the card so I cannot just reset and re-connect to the fresh Spi.
My only option seems to be finding a way to get it to reset through an Spi call, or look at creating a function to recover the sd back to its' expected state from whatever lock it is in.
With that in mind, is there a command or set of commands I can use to cause the equivalent of a reset, or to cancel whatever the microSD controller is expecting?
Looking at the SD associations' specs, the only reset reference is the CMD0 and that isn't applicable once into Spi mode.
Any thoughts are welcome, and thank you in advance.
-Chris
I tested and understood SDO rx and tx with the LPC11Cxx demo. But this demo stack has only SDO functions and a driver API. I want to implement PDO for the same. What would be some sample code or implementation steps or functions?
I want to send 68 (ADC data) bytes of data from a slave node to the master node at regular intervals. How can I do that?
For the above task, is SDO better than PDO? How many PDOs do I need to send 64 bytes of data? How can I set PDO mapping and parameters? What is the difference between a master node and a slave node? How do I differentiate from code?
I'm not sure of your example, but if you can send an SDO over the CAN bus, the you should be able to use the PDO, albeit more complicated.
The general steps are:
1. Define your PDO. You are creating a mapping between a PDO and one or more data objects in your node. For example, on my system, I created a Transmit PDO that sets the motor position and velocity (two objects) that responds with another PDO (a receive PDO) that contains motor current, position and status. This is the definition of the PDO.
To use your PDO, send out a PDO message with the COBid you defined in step 1. Fore me, I send PDO 0x201 with the position and velocity. The node will receive this and set the values you give to the object mapping you define. Note the node does NOT act on the data yet.
After you've sent as many PDO's you need (for example, I send PDO for position/velocity to 7 nodes on a bus to control 7 motors), you then send a SYNC. This causes the nodes to act on the PDO data you've sent - ie move the motors.
Each node will respond with a transmit PDO to send back whatever you define. My nodes send position, status, and current.
Repeat as needed.
Google "CANOpen momento dupin" for some example in the document. You'll have to read the doc on your nodes to understand how they are defined, or the chapter in the embedded canopen book. I have some old code you can look at the was provided to me from a vendor. That might be a good source as well. Nodes don't have to support PDO mapping but I think most do.