IMXRT1062 Hardfault Reading CAN3 ERFCR Register

[michaelsmorto]

According to the 1060RM setting the ERFCR will enable the Enhanced FIFO.  However when I try to even read the register in the FLEXCAN  example it throws a hard fault.  When I tried it in my own application on a imxrt1062 I also get a hard fault at that register address.  Needless to say I can't set it either.

So the question is, what is the cause of the issue and is Enhanced FIFO even enabled and the RM is incorrect?

[kerryzhou]

Hi Tom Evans and Michael Smorto,

 After the communication with our related departments again, it is confirmed, CANFD can't support the enhanced function.

Will update reference manual recently, and then update header file accordingly.

  Thanks again for your contribution.

Have a great day,
Kerry

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

- We are following threads for 7 weeks after the last post, later replies are ignored
Please open a new thread and refer to the closed one, if you have a related question at a later point in time.
-------------------------------------------------------------------------------

[michaelsmorto]

One last question.

While FIFO is not supported by CANFD FIFO is supported in legacy mode for CAN2.0?  Is that correct or is FIFO not supported at all? 

[kerryzhou]

Hi Michael Smorto and Tom Evans,

    RT1060 CANFD legacy mode can support the FIFO, just not the enhanced function, I already check it with our related department. I also tested some legacy mode register, didn't meet the hardfault problem.

   Now, do you meet any legacy mode FIFO problem on your side? If you have any question about it, please kindly let me know.

@Tom Evans,

    Sorry for delete your post, I just want to delete my last reply, and give the new reply, but it seems your reply is deleted, sorry about it.

Have a great day,
Kerry

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

- We are following threads for 7 weeks after the last post, later replies are ignored
Please open a new thread and refer to the closed one, if you have a related question at a later point in time.
-------------------------------------------------------------------------------

[michaelsmorto]

Sorry Kerry - false alarm.

We got all modes working with the 1062 on the Teensy T4 with the exception of course of the enhanced FIFO for CAN-FD. 

[kerryzhou]

Hi Michael Smorto,

     Thanks a lot for your information.

    So, now, still like our AE department confirmation, just enhanced FIFO can't be supported in the CAN-FD. This part information will be removed from the RM, this request already post to our related doc department. Sorry for our inconvenience bring you.

   Now, if you still have question about this case, please kindly let me know.

   If your question is solved, please help me to mark the correct answer, just to close this case, thank you!

Have a great day,
Kerry

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

- We are following threads for 7 weeks after the last post, later replies are ignored
Please open a new thread and refer to the closed one, if you have a related question at a later point in time.
-------------------------------------------------------------------------------

[buescher]

Note : It's not only the enhanced FIFO. It's also the enhanced timing registers that don't work, which is very unfortunate for CAN FD with bitrate switch !

Von: kerryzhou

Gesendet: Donnerstag, 24. Oktober 2019 05:28

An: Wolfgang Büscher

Betreff: Re: - Re: IMXRT1062 Hardfault Reading CAN3 ERFCR Register

NXP Community <https://community.freescale.com/resources/statics/1000/35400-NXP-Community-Email-banner-600x75.jpg>

Re: IMXRT1062 Hardfault Reading CAN3 ERFCR Register

reply from Kerry Zhou <https://community.nxp.com/people/kerryzhou?et=watches.email.thread> in i.MX RT - View the full discussion <https://community.nxp.com/message/1223282?commentID=1223282&et=watches.email.thread#comment-1223282>

[kerryzhou]

Hi Wolfgang Buescher,

  Yes, the related register I have reported to the related department, they told me all the related information in the RM will be fixed in the future.

   Thanks a lot for your contribution.

Have a great day,
Kerry

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

- We are following threads for 7 weeks after the last post, later replies are ignored
Please open a new thread and refer to the closed one, if you have a related question at a later point in time.
------------------------------------------------------------------------------

[kerryzhou]

Hi Tom Evans and Michael Smorto,

    Thanks a lot for both of your effort and time.  

     In factor, I also tested the other enhanced function on my side, I have reproduced the problem, BTE can't be set, EPRS, ENCBT, EDCBT and ETDC will also enter hardfault. So, I already send my test result and code to our related department, and report the problem, if it is confirmed the bug, they will help to update both the document and the SDK header file in the future.

    If I get the confirmation feedback, I will let you know ASAP.

    Thanks again for the contribution.

    About the supervisor mode, from the RM, it can be set in CAN_MCR[SUPV]

I write this code to test it:
    PRINTF("\nMCR= %X",  EXAMPLE_CAN->MCR );
    EXAMPLE_CAN->MCR |= (1<<23); // BTE
    PRINTF("\nMCR= %X, set SUPV bit",  EXAMPLE_CAN->MCR );
    EXAMPLE_CAN->MCR &= ~(1<<23); // BTE
    PRINTF("\nMCR= %X, clear SUPV bit",  EXAMPLE_CAN->MCR );

You can find it can be set to supervisor mode or the user mode.

Wish it helps you!

Kerry

[TomE]

> About the supervisor mode, from the RM, it can be set in CAN_MCR[SUPV]

That didn't answer his question.

Your answer says how to change how the CAN module responds to the different CPU User/Supervisor accesses. Michael asked how to write code to make the CHIP (the CPU core) generate those different cycles.

This isn't in the RM because there are almost no details about the CPU core in there. There are only three pages on the core in Chapter 27. It would help if that section said where to look for the documentation, but it doesn't.

Section "1.1.3.1 General Information" says:

For information about the ARM Cortex processor see:
* http://infocenter.arm.com

NXP and everyone else gets their cores from ARM because that means they don't have to design, test, document or write compilers for their own (usually custom) cores any more. This also keeps them on the leading edge of performance, features and power.That's why there haven't been any new ColdFire-based chips lately.

The ARM web site is very complicated and it is difficult to get the details for the specific core that is in the chip you're interested in. There are a huge number of different cores, and also lots of different options for each core that a manufacturer can select. Then there's a lot of optional extras and peripherals, like memory or bus interfaces that might or might not be present. Google finds this to (start to) answer Michael's question:

Assembler User Guide: Processor modes, and privileged and unprivileged software execution 

Tom

[kerryzhou]

@Michael Smorto, @Tom Evans,

   I am so sorry for my later reply, and this case is really opened so long time, it's my fault!

   I have checked it with our related department, and try to get the related FlexCAN enhanced RX FIFO validation code, and also report this problem.

   But at last, I have been told that the RT1060 can't support the enhanced RX FIFO function, that's why both of you enter the hardfault, it's not the code problem.

It's totally the RT1060,RT1064 reference manual bug, and I also get this information today. I already push the related department help to fix the reference manual bug ASAP.

And the related document will be fixed recently and updated in the official website.

   At last, please accept my apologize again, sorry for the inconvenience we bring you !

  I have been told that in the new chip RT1170, RT1070 will contain the FlexCAN enhanced RX FIFO function, maybe this information is useful to you.

Best Regards,

Kerry

[TomE]

Kerry Zhou wrote:

> But at last, I have been told that the RT1060 can't support the enhanced RX FIFO function,

> It's totally the RT1060,RT1064 reference manual bug.

That's not the only document that doesn't match the CAN FD hardware that is in the chip.

This "Enhanced Features in i.MX RT1060 Application Note" dated September 2018 lists the "Full-featured enhanced Rx FIFO" as being there (or intending to be there):

https://www.nxp.com/docs/en/application-note/AN12240.pdf 

All of these "Enhanced" registers are also defined in the SDK  in "/devices/MIMXRT1062/MIMRX1062h".

That's not all that is missing in that module.

The "Enhanced CAN Bit Timing Prescalers", "Enhanced Nominal CAN Bit Timing", "Enhanced Data Phase CAN bit Timing" and "Enhanced Transceiver Delay Compensation" registers and functionality aren't there. These are all enabled by "CAN_CTRL2[BTE]". This is bit 0x2000 in register 0x401D8034. This bit should not work as the registers it controls don't exist. This works correctly - that bit doesn't seem to be implemented. I can't set it.

(gdb) reset
Resetting target
(gdb) x 0x401D8000
0x401d8000: 0x5980000f
(gdb) set *0x401D8000 = 0x5980080f
(gdb) x 0x401D8000
0x401d8000: 0x5980080f
(gdb) x 0x401D8034
0x401d8034: 0x00800000
(gdb) set *0x401D8034=0x00802000
(gdb) x 0x401D8034
0x401d8034: 0x00800000‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍

But there's something else missing from the CAN_CTRL2 register. According to the Reference Manual, the bits 0xCFFFFBC0 should be read-write. Or 0xCFFFDBC0 when "BTE" is removed. But I'm only getting:

(gdb) set *0x401D8034=0xffffffff
(gdb) x 0x401D8034
0x401d8034: 0xcfffd800
‍‍‍‍‍‍‍

The MBTSBASE and TSTAMPCAP fields are missing as well. They're the "Message Buffer Time Stamp Base" and "Time Stamp Capture Point". Those wishing to program this part might like to compare the i.MXRT1060 manual with this one, which seems to be a better match to the model/version of the FlexCAN part:

https://www.nxp.com/docs/en/reference-manual/MPC5746CRM.pdf 

> I have been told that in the new chip RT1170, RT1070

Have those chips been announced? We've managed to find one mention in a "Roadmap" document only. Google now finds this post mentioning that part too.

Tom

[kerryzhou]

Hi Tom Evans,

   Thanks a lot for your effort to test it.

   Today, I also help you to double check it with our internal department.

   They said, the CANFD just can't support enhanced RX FIFO and the DMA transfer, but other enhanced function which you mentioned still can be support. So maybe it is not the chip function problem, we still need to do more testing.

   Could you create a new question post about your CANFD enhanced issue? Because this post is really very long. Then I will help you check more details in your new question post.

   About the RT1170 and RT1070 announced time, I also help you to check it.

   1. RT1170,  it will be announced in October, but the mass production will in the next year.

    2. RT1070 will be announced in the next year.

Thanks a lot for your understanding.

Have a great day,
Kerry

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

- We are following threads for 7 weeks after the last post, later replies are ignored
Please open a new thread and refer to the closed one, if you have a related question at a later point in time.
-------------------------------------------------------------------------------

[michaelsmorto]

@KerryZhou, @TomEvans

I tend to agree with Tom, Kerry,  besides the documentation identifying that FD enhanced FIFO exist and the application documentation that Tom referenced the SDKs all have those registers identified as being available, that is until you go to try and use them. 

Guess I would also ask the question is that if everything is pointing to enhanced FD features being available what happened that its not "supported".  Or is it available but NXP is just supporting that feature on the 1062. 

This leads me to another question that we asked but kind of skipped over - how to you programmatically put this chip into supervisory mode and/or user mode since it is talked about in the RM but not addressed anywhere on how to do that.

[TomE]

Kerry Zhou wrote:

> They said, the CANFD just can't support enhanced RX FIFO and the DMA transfer,

> but other enhanced function which you mentioned still can be support.

Prove it. Post some code that shows those functions being enabled. It has taken 3 months to get to "no Enhanced FIFO".

I can't see how the other functions could work. The registers that control those functions simply aren't there. Multiple tests show that. The Reference Manual says the registers exist, but are always zero when not enabled.

> So maybe it is not the chip function problem, we still need to do more testing.

Please get that testing done and report back.

> Could you create a new question post about your CANFD enhanced issue?

Why? This whole post is about the "Enhanced" functions not working.

It seems strange that we are reverse-engineering what the chip can and can't do over three months in this forum. NXP Engineering should know what the chip can do, and should have (or should be able to quickly generate) a Reference Manual Chapter that matches the silicon. That may take a while, so a "Reference Manual Errata" detailing the differences would help until then.

All we want is a Reference Manual that matches the chip. Sometimes this takes a while, six years in the case of getting  the correct  EDMA chapter for the MCF5441x Reference Manual:

https://community.nxp.com/message/1013864 

Tom

[michaelsmorto]

@KerryZhou, @TomEvans

Really appreciate the answer that the RT1060/1064 doesn't support the enhanced RX FIFO function.  Saving me time now.  That may be why those registers can not be used - they are locked.  At least it should be available in the 1170/1070.  The RM really should be updated.

Respectfully

Mike

[buescher]

I think the hard fault is due to the address range (offset) within the CAN controller.

I have a very similar effect (hard fault) when trying to access the 'EPRS' register (with "Extended Nominal Prescaler Division Factor" etc, which I need for fine-tuning the samping point for higher bitrates as recommended by CiA for CAN FD). Here, using an RT1064 (eval board), and yes, I am in "freeze mode", and even a READ access to this part of "FlexCAN3" (the only one with -FD) causes a hard fault here:

C (own code, this is not in fsl_flexcan.c) :

     base->EPRS = (base->EPRS & ~CAN_EPRS_ENPRESDIV_MASK) // IMXRT1064RM Rev 0.1 page 2759
                | CAN_EPRS_ENPRESDIV(config->preDivider);

generated ASM with remarks from single-stepping:

LDRH   r1,[r5,#0x00]
LDR    r0,[r4,#0xBF0] ; with R4=0x401D8000=CAN3_BASE, + offset 0xBF0 -> "EPRS". But: Hard Fault here !
BFI    r0,r1,#0,#10      ; never got here..
STR    r0,[r4,#0xBF0] ; would a WRITE ACCESS to "EPRS" also crash ? to be continued...

EPRS is at offset 0xBF0, thus sufficiently close to the Enhanced FIFO registers mentioned in the begin of this thread. I don't think there is a fine-grained equivalent of an "I/O permission bitmap" (Intel x86 slang) that looks at the least significant bits of the register address, but maybe the entire block of addresses is locked. The question is how to unlock this address range.

Eagerly waiting for a response from the experts..

   Cheers and thanks in advance,

       Wolf .

[TomE]

> EPRS is at offset 0xBF0, thus sufficiently close to the Enhanced FIFO

> registers mentioned

I wrote:

>> Note that NONE of the "Extended" registers can be read.

I meant "Enhanced". I hadn't looked closely enough to realise there two two different "Enhanced" functions in here - the "Enhanced RX FIFO" and the "Enhanced CAN Bit Timing".

Neither of their register sets are responding.

So checking all addresses and some of the ones between the different blocks:

(gdb) x 0x401d8000            # MCR
0x401d8000: 0x5980000f
(gdb) x 0x401d8050            # CBT
0x401d8050: 0x00000000
(gdb) x 0x401d8054            # CBT + 4
0x401d8054: Cannot access memory at address 0x401d8054

(gdb) x 0x401d8880            # RXIMR0
0x401d8880: 0x3c87987f
(gdb) x 0x401d897c            # RXIMR63
0x401d897c: 0x713fb422

(gdb) x 0x401d8980            # RXIMR63 + 4
0x401d8980: Cannot access memory at address 0x401d8980

(gdb) x 0x401d8bf0            # EPRS
0x401d8bf0: Cannot access memory at address 0x401d8bf0
(gdb) x 0x401d8bf4            # ENCBT
0x401d8bf4: Cannot access memory at address 0x401d8bf4
(gdb) x 0x401d8bf8            # EDCBT
0x401d8bf8: Cannot access memory at address 0x401d8bf8
(gdb) x 0x401d8bfc            # ETDC
0x401d8bfc: Cannot access memory at address 0x401d8bfc

(gdb) x 0x401d8c00            # FDCTRL
0x401d8c00: 0x80000100
(gdb) x 0x401d8c04            # FDCBT
0x401d8c04: 0x00000000
(gdb) x 0x401d8c08            # FDCRC
0x401d8c08: 0x00000000

(gdb) x 0x401d8c0c            # ERFCR
0x401d8c0c: Cannot access memory at address 0x401d8c0c
(gdb) x 0x401d8c10            # ERFIER
0x401d8c10: Cannot access memory at address 0x401d8c10
(gdb) x 0x401d8c14            # ERFSR
0x401d8c14: Cannot access memory at address 0x401d8c14

(gdb) x 0x401d8c18            # ERFSR + 4
0x401d8c18: Cannot access memory at address 0x401d8c18
(gdb) x 0x401d8c20            # ERFSR + 8
0x401d8c20: Cannot access memory at address 0x401d8c20
(gdb) x 0x401d8c24            # ERFSR + 0x0c
0x401d8c24: Cannot access memory at address 0x401d8c24
(gdb) x 0x401d8c28            # ERFSR + 0x10
0x401d8c28: Cannot access memory at address 0x401d8c28
(gdb) x 0x401d8c2c            # ERFSR + 0x14
0x401d8c2c: Cannot access memory at address 0x401d8c2c

(gdb) x 0x401d8c30            # HR_TIME_STAMP0
0x401d8c30: Cannot access memory at address 0x401d8c30
(gdb) x 0x401d8c34            # HR_TIME_STAMP1
0x401d8c34: Cannot access memory at address 0x401d8c34
(gdb) x 0x401d8c38            # HR_TIME_STAMP2
0x401d8c38: Cannot access memory at address 0x401d8c38
(gdb) x 0x401d8c3c            # HR_TIME_STAMP3
0x401d8c3c: Cannot access memory at address 0x401d8c3c
(gdb) x 0x401d8c40            # HR_TIME_STAMP4
0x401d8c40: Cannot access memory at address 0x401d8c40
(gdb) x 0x401d8d2c            # HR_TIME_STAMP63
0x401d8d2c: Cannot access memory at address 0x401d8d2c

(gdb) x 0x401db000            # ERFFEL0
0x401db000: Cannot access memory at address 0x401db000
(gdb) x 0x401db004            # ERFFEL1
0x401db004: Cannot access memory at address 0x401db004
(gdb) x 0x401db008            # ERFFEL2
0x401db008: Cannot access memory at address 0x401db008
(gdb) x 0x401db1fc            # ERFFEL127
0x401db008: Cannot access memory at address 0x401db1fc
‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍

Tom

[buescher]

Very similar result here, on an RT1064...

32-bit-wise readable locations within i.MX RT1064 "CANFD/FlexCAN3", base 0x401D8000:

0x401D8000 ... 0x401D8008 : readable     (MCR, CTRL1, TIMER)
0x401D800C                : not readable (ok, no documented register here)
0x401D8010 ... 0x401D8038 : readable     (RXMGMASK, RX14MASK,....ESR2)
0x401D803C ... 0x401D8040 : not readable (ok, no documented register here)
0x401D8044 ... 0x401D8050 : readable     (CRCR, RXFGMASK, RXFIR, CBT)
0x401D8054                : not readable (ok, no documented register here)
0x401D8058 ... 0x401D805C : readable     (ummm.... undocumented registers here)
0x401D8060 ... 0x401D807C : not readable (ok, no documented register here)
0x401D8080 ... 0x401D847C : readable     (a lot of undocumented registers here)
0x401D8480 ... 0x401D887C : not readable (ok, no documented register here)
0x401D8880 ... 0x401D897C : readable (Rx Individual Mask Registers RXIMR0 - RXIMR63)
0x401D8980 ... 0x401D89DC : not readable (ok, no documented registers here)
0x401D89E0                : readable     (undocumented register)
0x401D89E4 ... 0x401D8BEC : not readable (ok, no documented registers here)
0x401D8BF0 ... 0x401D8BFC : not readable (EPRS, ENCBT, EDCBT, ETDC)
0x401D8C00 ... 0x401D8C08 : readable     (FDCTRL, FDCBT, FDCRC)
0x401D8C0C                : not readable (ERFCR)
0x401D8C10                : not readable (ERFIER)
0x401D8C14                : not readable (ERFSR)
0x401D8C18 ... 0x401D8C2C : not readable (ok, no documented registers here)
0x401D8C30 ... 0x401D8D2C : not readable (High Resolution Time Stamp 0..63)
0x401D8D30 ... 0x401D8FFC : not readable (ok, no documented registers here)

Just speculation at the moment: *Some* of these registers may be accessable only after configuring the controller (FlexCAN3 in my case) for CAN FD, not standard CAN. But many should, imo, be accessable in both "CAN" and "CAN FD" mode. Will check if this really has an impact on these register's readability. Or maybe the register offsets in the manual are partly wrong (note the existance of a few "undocumented" registers that are readable *without* causing a HardFault).

Cheers,

   Wolf .

[TomE]

Wolfgang wrote:

0x401D8058 ... 0x401D805C : readable     (ummm.... undocumented registers here)
0x401D8080 ... 0x401D847C : readable     (a lot of undocumented registers here)
0x401D89E0                : readable     (undocumented register)
‍‍‍

These are in "/devices/MIMXRT1062/MIMRX1062.h" as:

  __I  uint32_t DBG1;    /**< Debug 1 register, offset: 0x58 */
  __I  uint32_t DBG2;    /**< Debug 2 register, offset: 0x5C */

  __IO uint32_t GFWR;    /**< Glitch Filter Width Registers, offset: 0x9E0 */
‍‍‍‍

The bits in the debug registers are documented in the header.

The "0x401D8080" address is the start of the "Embedded RAM", documented in "44.6.1 FlexCAN Memory Mapping" in the Reference Manual.

The "GFWR" is documented at that offset address in the non-FD FlexCAN chapter, but not in the FD chapter.

Tom

[TomE]

That's great testing, Wolfgang. Were you able to automate that, or did you check all the addresses manually, like I did?

If you've automated it (if you have code that can recover from the bus error), then it might be interesting to see which of the "undocumented" registers are fully read-write (like RAM) and which ones have bits you can't write to (like a control register). It is also possible that some of those address ranges "mirror" some of the other addresses. You could write some code that spots any address mirroring.

That wouldn't tell us anything useful though. Just something we can do to pass time while waiting for a response from NXP.

It has been 10 days since Kerry said "I will contact with our internal side", and over 14 weeks since this problem was first reported here.

Tom