imxrt fixes

[davids5]

In bringing up the NXP RDDRONE-FMURT6 these issues were discovered and fixed.

• False detection
• No Detection I2C
• System lock up hang due to interrupt storm

Prior to this PR

NuttShell (NSH)
nsh>  i2cdetect -b 1
Scanning I2C bus: 1
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
70: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
nsh>  i2cdetect -b 2
Scanning I2C bus: 2
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00: 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d <HUNG>

Top Traces are the I2C IRQ, SPI IRQ and CPU IRQ,
Big Picture

Focus on Storm

The Storm rate.

With this PR

NuttShell (NSH)
nsh>  i2cdetect -b 1
Scanning I2C bus: 1
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00: -- -- -- -- -- -- -- -- -- -- -- -- -- -- 0e --
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
50: -- -- -- -- -- 55 -- -- -- -- -- -- -- -- -- --
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
70: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
nsh>  i2cdetect -b 2
Scanning I2C bus: 2
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- 1e --
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
70: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --

[Apache9]

So we will merge PR to master branch directly? No dev branch?

[davids5]

So we will merge PR to master branch directly? No dev branch?

@Apache9
As it stands master has been dev. If we had release branches then master could still be dev. But all this is yet to be seen.

I will let this sit until the PPMC votes on work flow. I only needed it merged to backport to the PX4 stable version of nuttx 8.2. It was important because it cause the OS to hang.

I usually prefer to back-port after Greg has applied the patch or PR and then fixed things his subsequent commits. That way the back port == upstream.

But I can carry the commits without the [BACKPORT] marker in PX4 for now.

We should warn all the NXP IMXRT and I think NXP S32K users the code will hang the OS.

[patacongo]

'master' has never been 'dev' in this repository. You are thinking of a different repository that was managed by a single person.

[davids5]

'master' has never been 'dev' in this repository. You are thinking of a different repository that was managed by a single person.

Yes - I am so glad you are so exacting - I was referring to historically before NuttX joined ASF. Most recently in the repo hosted on bitbucket, with Greg as the sole committer.

[patacongo]

With a single committer, you can greatly simplify things since it is the sole reponsibility of that single committed to go from the patch to PR to its clean incorporation. It requires more discipline to work as a group.
PS: I always hated the PRs to master in the Bitbucket repsitories. But I never hated all PRs as you said. I should have set up a 'dev' branch and made sure that all PRs were against the 'dev' branch. Although it does take a little effort to keep a dev branch up to date.

[btashton]

@davids5 This touches some of the same IO stuff that I have been working on on the imxrt platform, some of the changes are style. Did you make these changes via one of the existing tools, or was this manual. I want to make sure my changes apply cleanly on top of this. For now I will carry this in my tree.

[jarivanewijk]

Thank you for your work, @davids5!

We should warn all the NXP IMXRT and I think NXP S32K users the code will hang the OS.

A lot of the peripheral code for S32K seems to be taken from i.MX RT, so it is likely affected by this is as well. There are probably not many S32K users yet, though. We are working at NXP to improve the support for the S32K1xx and their evaluation boards. The progress is slow but steady. After the holidays I will apply your fixes to S32K on our internal NuttX repository. We will open a PR here eventually. (January/February?)

[davids5]

Thank you for your work, @davids5!

We should warn all the NXP IMXRT and I think NXP S32K users the code will hang the OS.

A lot of the peripheral code for S32K seems to be taken from i.MX RT, so it is likely affected by this is as well. There are probably not many S32K users yet, though. We are working at NXP to improve the support for the S32K1xx and their evaluation boards. The progress is slow but steady. After the holidays I will apply your fixes to S32K on our internal NuttX repository. We will open a PR here eventually. (January/February?)

@jarivanewijk - yes exactly. It was cloned by @patacongo before I had the RDDRONE-FMURT6 HW to validate it on. It may be marked EXPERIMENTAL , but I have not followed it's progress.

I will ask @igalloway for HW and I can cross check locally as well.

[davids5]

@btashton

@davids5 This touches some of the same IO stuff that I have been working on on the imxrt platform, some of the changes are style. Did you make these changes via one of the existing tools, or was this manual. I want to make sure my changes apply cleanly on top of this. For now I will carry this in my tree.

yeah - we really should talk this through. I had a very detailed discussion on yahoo on what we had learned from the STM32 organically grown nightmare.

The gist of it is: There are clear patterns that should be use when there is a chip family.

@mubes make some great strides in this on the RT, but took some shortcuts when the imxrt20 came in. We should not follow that pattern.

All the gpio tables need to broken out and the included like the clockconfig does STM32 or the dasiy does n the imxrt.

#ifddef rash has to be avoided or kept to a minimum. It use to be before the 20 commit.
Scope has to be be maintained.

Let' plan a call then bring it back to the list.

[mubes]

Way back when DavidS and I talked about this at length and then there was a lot of work done in imxrt to split it into the different chips - 1050, 60 and 20 to form the various hardware/rt10xx directories.

At the moment the only place there is any family member selection (other than to pull in the correct chip specific subdir) is in imxrt_clockconfig.c, imxrt_gpio.c and imxrt_iomux.c. Those can (and probably should) be refactored into the same pattern as the other files which, I think, would keep the structure clean.

Does that satisfy your concern @btashton , or are you looking for a more fundamental restructure? (BTW, this structure is a nicer way of highlighting changes and having proper discussion about them to find the best way forward).

DAVE

[btashton]

@mubes No complaints on my end (beyond the tedious task of transcribing datasheets to code). This family has been handled so much better by NXP than ST did with the STM32 family.

There are a few things I have tweaked across all of the devices, but that is mostly minor and usually just using a better define for example because not all have PADMUX_WAKEUP:

-  if (index >= IMXRT_PADMUX_WAKEUP_INDEX)
+  if (index >= IMXRT_PADMUX_SNVS_START_INDEX)

Also a couple typeo's like

-#define GPIO_LPSPI1_SDI_2              (GPIO_PERIPH | GPIO_ALT4 | GPIO_PADMUX(IMXRT_PADMUX_GPIO_SD_B0_05_INDEX))fb
+#define GPIO_LPSPI1_SDI_2              (GPIO_PERIPH | GPIO_ALT4 | GPIO_PADMUX(IMXRT_PADMUX_GPIO_SD_B0_05_INDEX))

There is also a GPIOMUX that they added to help with the lower pincount while still allowing high speed GPIO. Anyway I need to just get this stuff out for comment. Probably need a couple nights to get the core code done, not sure how long the board bit will take. The memory interfaces are a little different.

Anyway this is getting off topic for this PR. I'll put a DRAFT PR up before I get the board code done, either a here or on my fork.

@davids5 I have not forgotten about your offer, just will likely need to wait until the 1st with travel.

[mubes]

Yeah, lets move this onto another PR so we can fix up whatever needs to be done to solidify the filesystem structure for the rt's. Certainly I think moving the GPIOs, IOMUX and ClockConfig into the subdirectory will go a long way to fixing whats outstanding (well, that and fixing Mr. Hamfisteds' typos).

DAVE