NNDK 2.7.0 Status?

[sblair]

I wanted to check and see what the current state of 2.7.0 is particularly for use with the MOD5441x platform and what everyone's experience is so far?

Are there any regressions that have been discovered in it to be aware of? Any reasons to not use it?

I've been stuck at 2.6.7 for a while to avoid the regressions in the last several releases, but I also need to start some work on a new product using the MOD54417 so I'd like to get some of the newer stuff which at this point means Beta 2.7.0. Of course I'll need to leave my production build server on 2.6.7 until it hits stable release status.

What is the expected schedule for when 2.7.x will be at stable status?

Thanks!
Scott

[dciliske]

The only regressions I'm seeing reported are a printf that got left in the DSPI driver, and possibly one that I don't want to mention because then it will be my bug. (I think it's a stack overflow on their end, and I have yet to replicate it, but the moment I say it's not us, well...).

[ecasey]

NNDK 2.7.0 seems to work fine with my MOD54415s, but not with my MOD5282s. I posted about this earlier
See http://forum.embeddedethernet.com/viewt ... f=5&t=2121 for details.
Should I raise a support ticket on this?

Ed

[dciliske]

We just resolved the 5282 issue. TL;DR version: improved Tick accuracy on all platforms, screwed up the instruction width on the MOD5282, IRQ flag didn't get cleared, posted the bsp.c change to fix it. See the linked topic.

-Dan

[roland.ames]

I have found a change in the MOD5441X OpenSerial() function when used on ports 0,1,2.
This function used to write 0xFF to the relevant PAR register, now it writes 0x0F.
The difference here is that the RTS/CTS pins are being set to their GPIO function, whereas before they were being set to their primary function (RTS/CTS).

This caused a problem because I am using h/w flow control, and now I must write to the par (using the pins function) after calling OpenSerial(), to ensure the rts/cts pins are set to their primary function.


There should be some consistency across modules as to what the OpenSerial(), SerialEnableHwTxFlow() and SerialEnableHwRxFlow() functions do to the pin assignment registers. The MOD5441X code for enabling/disabling h/w flow control does not do any writes to pin assignment registers, but the equivalent functions for eg MOD5234 do force the relevant pins into the primary function.

MOD5441X code for OpenSerial() used to force data and control pins to their primary function, but now only does this for the data pins.

[dciliske]

The change was due to the fact that if you opened uart_4 or uart_5 and then reopened uart_0 or uart_1 later, it would clobber those uarts. This is not expected behavior. The decision was, given that hardware flow control needs to be enabled already, that it would make sense to remove changing the function of those pins (which never should have been part of open serial anyways...). This was a conscious change, not a regression.

...and of course it's not in the change notes; I don't know why. I guess because we thought that it wouldn't be possible to care? I have no idea, I guess I'll ask tomorrow...

-Dan

[dciliske]

As for writing to the PAR, you do know of the SerialEnableHw*Flow() right? Section 20.7/20.8 of the manual. There may be an issue I was unaware of, but I thought that would do what you're commenting about.

-Dan

[roland.ames]

SerialEnableHw*Flow() for MOD5441X does not write to the relevant PAR, it only configures the UART.

SerialEnableHw*Flow() for MOD5234 (and others?) does write to the relevant PAR, as well as configures the UART. If flow control is enabled, the pin is assigned as primary (rts/cts) function. If flow control is disabled, the pin is assigned as GPIO.

[dciliske]

You are right about both the failure for the MOD5441X and the behaviour of the other platforms. The Nano even behaved correctly! Clearly there was a fork at some point between the Nano and Mod drivers and things didn't transfer. We've corrected the par issue and merged the Nano and Mod drivers back together, so there won't be any further divergence.

I guess this will be waiting for 2.7.1...

-Dan

[roland.ames]

The change was due to the fact that if you opened uart_4 or uart_5 and then reopened uart_0 or uart_1 later, it would clobber those uarts. This is not expected behavior. The decision was, given that hardware flow control needs to be enabled already, that it would make sense to remove changing the function of those pins (which never should have been part of open serial anyways...). This was a conscious change, not a regression.

...and of course it's not in the change notes; I don't know why. I guess because we thought that it wouldn't be possible to care? I have no idea, I guess I'll ask tomorrow...

-Dan

The current OpenSerial for MOD5441X, forces the relevant rts/cts pins to the GPIO function, it does not leave them unchanged as the equivalent functions for other modules does.

for serial port0, the previous version of Open Serial did

Code: Select all

	  case 0:
			IsrFunction=(unsigned long)SER_0_ISR;
			this_fd=SERIAL_SOCKET_OFFSET;
			//B10 and D11
			sim1.gpio.par_uart0=0xFF;

			break;

setting data and control pins to their uart functions

the new version of Open Serial does

Code: Select all

	  case 0:
			IsrFunction=(unsigned long)SER_0_ISR;
			this_fd=SERIAL_SOCKET_OFFSET;
			//B10 and D11
			sim1.gpio.par_uart0=0x0F;

			break;

setting data pins to their uart functions and control pins to GPIO

but I think it should be

Code: Select all

	  case 0:
			IsrFunction=(unsigned long)SER_0_ISR;
			this_fd=SERIAL_SOCKET_OFFSET;
			//B10 and D11
			sim1.gpio.par_uart0|=0x0F;

			break;

setting data pins to their uart functions, and not changing function of control pins