FlexCAN autobaud failure MKE16F512VLH16

xxxajk · ‎08-16-2017

If any other device on the CANBUS is actively participating, the ROM refuses to see the initial ping request, even if I specifically set the baud rate for FlexCAN in the BCA, which in my case is 0x02 (500K bauds).

Is there any thing short of powering down or forcing other devices to enter listen only mode when they see a ping packet?

The problem is quite large on the current board as there are 3 MCU always present. One MKE16F512VLH16, and Two MK20DX256. Additionally, up to an additional Seven MKE16F512VLH16, all on the CANBUS. Luckily the external 7 MKE16F512VLH16 are powered down during the update, but there is no way to power down the other two MK20DX256. In fact one of them is used to update the main MKE16F512VLH16.The core reason for having KBOOT in ROM is for the obvious benefit of the ability to recover from a botched flash operation, without worries of accidentally erasing the bootloader. Short of having to port KBOOT 2, and fixing the annoyance that I am seeing, are there any other recommendations to making a fallback to ROM work other than forcing all other modules into listen mode with a halt?

This device reports:

Current Version = K1.5.1

Kan_Li · ‎08-22-2017

Hi Andrew,

If you put multiple MCUs on one CAN bus, you have to set different ID for each MCU, the latest KBOOT has a Kinetis Bootloader Configuration Area (BCA) , which resides in flash memory at offset 0x3C0 from the beginning of the user application.

There are CAN ID settings in this area , and when you program the MCU firstly, you may download the BCA with user application to set up a can id for each mcu, then you may update the firmware via CAN bus with KBOOT.

Hope that helps,

Have a great day,
Kan

-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

xxxajk · ‎08-22-2017

That much I understand.

The automatic baud rate detection is what is not working when you have an active MCU on the CAN BUS.

Even if you specify the rate, it still fails to see the ping packet.

The ID does not matter and is not the issue.

Example setup that will demonstrate the problem.

PC -> MCU1 -> CANBUS

PC -> MCU2 -> CANBUS

TARGET MCU -> CANBUS

MCU1 used via BLHOST to upload code to TARGET MCU

MCU2 used to interact and monitor with TARGET MCU and/or MCU 1

At boot:

MCU1 is ACTIVE

MCU2 is ACTIVE, not in a passive listen only mode.

TARGET MCU is in the boot-loader.

TARGET MCU will NEVER see the ping packet, and is NOT able to automatically change to the required baud rate because MCU2 saw the packet and it is consumed.

So the question is, do I have to constantly RESEND the ping packet until the bootloader "sees" it, and how often in order to do that. BLHOST does not do this on its own, so it is something I will have to implement on MCU1.

Kan_Li · ‎08-23-2017

Hi Andrew,

Sorry for the misunderstanding! So you use MCU1 as an embedded host to download firmware into the TARGET MCU, right? so the MCU1 acts as something like the BusPal, right? Please kindly help to clarify.

Have a great day,
Kan

-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

xxxajk · ‎08-23-2017

Correct.

MCU1 and MCU2 are both Kinetis MK20DX256.

MCU1 takes the data from USB, emulating CDC-ACM (RS232) and places it right on the CAN BUS to the default ID, just as if it was actually using serial from blhost. It works great until MCU2 comes into play.

Currently MCU2 monitors and interacts with the CAN BUS, is active, and not in listen only mode.

Kan_Li · ‎08-23-2017

Hi Andrew,

Thanks for the information! What about the CAN id for MCU1 , MCU2 and TARGET MCU? Same or different? Please help to clarify. and if different, please specify the value.

Thanks for your patience!

Have a great day,
Kan

-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

xxxajk · ‎08-23-2017

Both are different IDs, but are set up to accept ALL incoming messages, no hardware filters used.

Kan_Li · ‎08-23-2017

Hi Andrew,

Thanks for the information! What are the actual values you set for the MCUs? Would you please specify?

Thanks for your patience!

Have a great day,
Kan

-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

xxxajk · ‎08-23-2017

TARGET MCU KBOOT ROM K1.5.1, using defaults TX_ID 0x123, RXID 0x321. Application firmware uses TX_ID 0x18000010, and listens for both regular and extended IDs with no ID masking in hardware, IDs are matched in software.

MCU1 uses for flashing TX_ID 0x321, and listens for both regular and extended IDs with no ID masking in hardware. ID is matched in software to send replies back to the PC host. For regular use TX_ID is 0x18000020.

MCU2 uses TX_ID 0x18000040, and listens for both regular and extended IDs with no ID masking in hardware, IDs are matched in software.

MCU1 and MCU2 are updated differently, not over CAN BUS.

Kan_Li · ‎08-24-2017

Hi Andrew,

Thanks for the information! but as what you mentioned before, "TARGET MCU is in the boot-loader", so may I understand that TARGET MCU still uses TX_ID 0x123, RXID 0x321 in your test? Actually no user application run on TARGET MCU when this issue occur, right? Please kindly help to clarify.

Thanks for your patience!

Have a great day,
Kan

-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

xxxajk · ‎08-24-2017

Correct. The KE1xF is running the boot loader ROM. Initial programming sets in the BCA to only have CAN active as well.

Current Version = K1.5.1
Available Peripherals = CAN
Flash Start Address = 0x00000000
Flash Size = 512 KB
Flash Sector Size = 4 KB
Flash Block Count = 1
Verify Writes Flag = ON
Max Packet Size = 32 bytes
RAM Start Address = 0x1FFF8000
RAM Size = 64 KB
System Device ID = 0x16270087
Flash Security State = UNSECURE
Flash Access Controller (FAC) Support Flag = SUPPORTED
Flash Access Segment Size = 8 KB
Flash Access Segment Count = 64
Flash read margin level = USER
Target Version = T1.0.0

BCA

0x3c0: 6b 63 66 67 ff ff ff ff ff ff ff ff ff ff ff ff
0x3d0: 08 ff e8 03 ff ff ff ff ff ff ff ff ff ff ff ff
0x3e0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x3f0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff

Kan_Li · ‎08-28-2017

Hi Andrew,

Thanks for the information! From my understanding, this issue is due to the MCU2 acked and received the CAN frames sent to TARGET MCU, so I am wondering if you used K20 100MHz part for MCU2, as I know, 100MHz part has two CAN module, so if you are using K20 100MHz part, you may use CAN0 for listen-only mode to monitor the CAN communication, and use CAN1 with unique ID for interacting with other CAN nodes.

Have a great day,
Kan

-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

xxxajk · ‎08-28-2017

Well, there are two other options then, since I am using the 72MHz part.

Hold all unwanted MCU in reset and/or power them down.

...or...

Watch for the ping, and when seen, send a NAK, and go into listen only mode. Return to normal mode after an ACK is seen.

What I find disappointing is that the target MCU can't seem to see the initial ping even when the baud is indeed specified. with the following values:

canConfig1: 0x02

canConfig2: 0xFFFF

Without sources to the actual ROM, I can't even know if there is some alternate trick, or if the IDs need to actually be set either. With the current KBOOT sources, that SHOULD place it into 500K baud and just work. but it does not.

Thus I have 2 requests.

The values for 500K baud that would force it and bypass the detection. Note: I am running crystal-less, if that makes any difference.
The actual K1.5.1 ROM source for this part.

Either/both could prove useful, especially sources for the ROM. Do not point me to the most recent KBOOT sources, as I already have them.

Thanks again for your time.

Kan_Li · ‎08-29-2017

Hi Andrew,

I am sorry, but the ROM source are confidential, you may check the KBOOT 2.0 source, the basic process are the same. and I noticed you mentioned you use crytal-less, but as I know, for CAN application, we always recommend external crystal as the internal crystal's jitter out of CAN spec, so maybe it works for some low baud rate, but better use an external crystal for your application.

Have a great day,
Kan

-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

xxxajk · ‎09-15-2017

What I had to do is hold on-board MCU in the reset state so they do not interfere.

While not exactly optimal, it works.

The drawback is that I can't monitor the progress of any updates.

Too bad that when you explicitly set the baud rate that it does not just accept it as it seems to be able to do in KBOOT 2. :-(

Perhaps it is time for NXP/freescale to make a newer ROM mask ;-)

xxxajk · ‎08-29-2017

Understood, so, does the following set 500Kbaud?

canConfig1: 0x02
canConfig2: 0xFFFF

Can you at least confirm this?

If not, what are the correct values for 500K baud crystal-less?

Thanks for your time.