Pin class and IRQs on 54415 parts

[Ridgeglider]

Could anyone provide additional info on several items related to the Nano54414:
1) Details of the pins class, and how that interface might differ from the RapidGPIO approach mentioned here: http://forum.embeddedethernet.com/viewt ... f=5&t=1542. The Nano pins class, instead of the more familiar J2.functon.XXXX syntax, (based on some of the examples) seems to use the following syntax:
Pins[27].function(PIN_27_CAN0_TX ).

2) While trying to get some DMA interrupts working, I see that the details of the SetIntc() macro look a bit different than on either the 5270, 5234, or even 5282 platforms and without a prio. Is this correct? If so, the corresponding entries for the nano and Mod54415 in C:\nburn\docs\NetBurnerRuntimeLibrary\uCOSLibrary.pdf may need updating too.
void SetIntc(int intcnum, long func, int vector, int level);

[pbreed]

Look in the platform include directory for intcdefs.h I'd use thoose macros on this platform.

Paul

[rnixon]

The Pins class are C++ objects, when you use rapid gpio you write directly to hardware, so I would expect rapid gpio to be significantly faster.

[rnixon]

The nano has only one connector, not J1 and J2, so that is why I think the connector designator is not included. I did notice the nano pins class designates pins on the NANO card edge connector, which come out to different pin numbers on the DEV BOARD. Confusing. Wish they were the same.

[dciliske]

Yea, on the Dev board note, the headers are labeled backwards with regards to the module/datasheet (Odds are even, evens are odd). I think there's a silkscreen change in the works, but don't quote me on that

Also, let me know if you run into any really bizarre trapping/stack overflow issues with the DMA stuff. I'm getting that going for the DSPI driver and... let's just say I'll be happy when I've found a way to fail meaningfully.

[Ridgeglider]

Dan: not sure I'm seeing the mis-labeling on the Nano headers. Here's what I see for the Nano edge connector (1st image), and then in the P2 and P3 headers (2nd image). The P1 schematic agrees w/ the datasheet: eg Pin 1 in Dev Board schematic schematic is the same as pin 1 in data sheet. I have not checked the edge connector itself, so maybe that's what is mis-labeled in both schematic and data sheet although, since you mentioned the headers (P2 & P3??), I don't think those are the pins you are suggesting that are backwards.

Next, as indicated in the 2nd image, the Dev Board P2 and P3 headers also appear to be properly labeled: P2 and P3 on the Dev Board both match schematic. These check out when testing the actual Ground vs 3.3V supply pins, (3.3V is positive wrt Ground). Additionally, all the pins labeled as P3 DT0-3 pins work as expect with DMA IRQ code. Bottom line: still not sure what pins are "backwards'??

With regard to getting traps for the DMA timer, I see no evidence of that either. My code builds on IRQs for each channel, pretty much like what's shown in the C:\nburn\examples\utils\HiResTimerDemo\HiResTimer.cpp Nano54415 section for setting up the INTERRUPT() and SetIntc() routines.

[dciliske]

Hmm... maybe we did make that silk screen change. I know that the actual labeling on my dev board (and at least one of the other engineers') at the office (rev 1.1) has the P2 and P3 headers mislabeled. It has the Even pins on the outside of the board and the odd pins on the inside. I'm not saying this to try and confuse you, but to give you a heads up if things don't seem to hook up correctly.

Oh, and by "DMA Interrupts" you are in fact referring to the DMA Timer/HiResTimer. I thought you were using the eDMA module on the part. That's where I'm having 'some' headaches.

[Ridgeglider]

Yes, I'm using the DMA Timers, not the eDMA...

Regarding pin labeling on the Nano Dev board: My board is rev 1.0. The schematic is R1.1... Hmm.
Is there a rev 1.0 schematic available? There seem to be a couple of jumpers: JP8 (to disconnect ADREF from VCC3V) & JP9 (to allow disconnection of USB_Rx)added between R1.0 and R1.1. These are pretty self-explanatory, although my R1.0 board does not have those jumpers. Still, a schematic would be... convenient in case there are other differences.
The P2 and P3 pins are labeled w/even numbers on the board edge....

I thought i was OK (and things seem to work), but am now a tad confused on what I should look out for.

Thx.

[dciliske]

There is not a rev 1.0 schematic available. The differences between rev 1.0 and 1.1 is the tx/rx line fix (which you probably have as greenwire) and adding those jumpers.

With regards to the pin numberings, I think I was unclear. The silkscreen says that the even pins are on the outside and the odds on the inside. Electrically the odd pins are on the outside and the even pins are on the inside. The silkscreen on the rev 1.0 and 1.1 dev boards is incorrect and has them flipped.

[mbaybutt]

Also, let me know if you run into any really bizarre trapping/stack overflow issues with the DMA stuff. I'm getting that going for the DSPI driver and... let's just say I'll be happy when I've found a way to fail meaningfully.

Hi Dan,

I have been experiencing odd trap behavior when using the timer->setInterruptFunction() functionality. I am attempting to establish a timer to trigger a function call at a rate of 4ms. After debugging the issue a bit, my sense is the issue lies in the interrupt capability not being reentrant. Meaning the trap condition seems to trigger if the timer expires before the previous call to the interrupt function returns.

As you alluded to, the trap information isn't exactly the most informative
-------------------Trap information-----------------------------
Stack is corrupt A7=00000034
Trap Vector =
Stack Frame seems corrupt unable to do RTOS dump

-------------------End of Trap Diagnostics----------------------

I have implemented a semaphore within the interrupt function to protect the shared variable memory, but the issue seems to lie in calling the function itself. I have a few ideas to try, but figured I would post here in case anyone else has seen this or has a solution for it.

Thanks,

- Mark