We are developing a application in C++ with VS2005.
Can any one please help. We need to reboot the system from the Software.
I know that there is a reboot command with NDCU CONFIG, but I look for a way not using the call of NDCU CONFIG because it is not accessable.
What command should I use?
Kind regards
Hai,
there are two kernel versions for each kernel release. One of them has an "_RTC_" in the middle. Can any one explain the differences between those two kernels?
Does it mean if I use the kernel wothout the "_RTC_" extention the system clock would not be supported?
I look forward hearing from you soon.
Kind regards
Hai,
we would like to use the WEB-server of the PicoCOM4. Can any one can give us advice how to activate it? Where can we find an example code?
We look forward hrearing from you soon.
kind regards
We have a PicoCOM4 R1.20 with kernel XIPNKPC4_CORE_CF2_121029.
We experiencing problems in opening the serial port COM1 at boot time.
In our application we need both serial ports (COM1 and COM2) to communicate. Our problem is the COM1 will not initialise and error is returned when we boot up the hardware with both netdcu config utility and debug output are disabled .
To check the hardware we have booted with the debugger and opend the serial ports one by one.
Serial debug output at boot time is disabled and the netdcu config utility reports on the interface COM1. After sending the command "quit" the utility exits. The application is started and runs with no errors.
To swichtch off the netdcu config utility we have put the system/ndcucfg/port to "COM3", whitch is not used. After saving the registry we rebooted with no netdcu config utility. The terminal only reports an boot promt "<0>". That the sign that the boot loader can still be called.
Now we start our application again, but an error is returned when opening COM1.
Please help urgently, because we are about to release our hardware with the PicoCOM4 for production shortly.
Hai there,
thank's for the quick answer. I have implemented this in our Software alredy, but PicoCOM4 does not respond as expexted.
Instead I am getting a strange puls siglal every one milisecond, see e-mail attachment.
I can not drive pin 69.
Please help.
Can any one help quickly?
How do I switch off the hardware handshake lines RTS1 und CTS1 within the serial port, so that I can use them for the digital I/O?
I need to drive PC4-Pin 69 as an output.
Hai,
1) I have checked the forum interface. I says:
QuoteSie dürfen neue Themen in diesem Forum erstellen.
Sie dürfen Antworten zu Themen in diesem Forum erstellen.
Sie dürfen Ihre Beiträge in diesem Forum ändern.
Sie dürfen Ihre Beiträge in diesem Forum löschen.
Sie dürfen keine Dateianhänge in diesem Forum erstellen
Can you give me access to append files to the forum?
Another option would be to copy/paste pictures into the text reagion like an html email design.
2) Your picture:
QuoteSPI-Mode3.png
makes sense to me. In acordance to the specification it looks correct.
I also agree with your definition of "latching" seen from the point of a receiving slave device. Basically I ment the same exept that I reffered to the master device action, which is the PicoCOM4 side.
3) program executing:
QuoteDoes the debug trace above include executing of your programm?
No. I start the program after system has booted up using the debug interface of the VS2005 Software.
4) call IOCTL_NSPI_SET_METHOD:
QuoteDoe you call IOCTL_NSPI_SET_METHOD within your application? Maybe
No. I am not changing the SPI settings while our program is executed.
5) test-application:
QuoteMaybe you can write a small test-application that simply writes some bytes to make sure that the mode really is correct.
I have done the test using the ecaxt code you have provided. I still get the wrong output.
This time I have tested two PicoCOM4 boards with different Hardware revisions. Test_001= R: 1.11 and Test_002= R:1.20.
The board was configured with the following file:
PS:Since I can not attach the pictures here I will email them to you instantly.
Hai again,
our messages some how got over each other. To your privous statement:
QuoteNo, in SPI Mode 3, data is valid on the first rising edge and it must also be latched on the rising edge of the clock signal. See attached image. Latching is done in the middle of the region of each bit, where the data is stable. Data changes on the falling edge. So latching on the falling edge would risk that the data is right within a change.
Just to clarify the meaning of "latching": data are changed at this moment, so in SPI mode 3 valid data are present between the latching process. That means data are valid on each rising edge of the CLK signal. Therefore the data change has to be done exactly in between the rising edges, so the data are changed/loaded at the falling edges (see your picture). For comparision look at the pictures I have emailed you. Also the device data sheet of the MCP4822 defines it clearly.
PS: I can not find the "attach file"-button. How do you attach a picture for example in such a message?
Hai,
after reconfiguration of the netdcucfg to port 2 und enabling the debug output in the boot loader, I get the following output:
PS: I have emailed you the output pictures of out application.
Hai there,
we migrating from PicoCOM2 to PicoCom4.
Our application is working with the PicoCOM2 but makes SPI communication problems with the PicoCOM4 modul.
Our SPI driver version is V3.2.
.
We operate in SPI mode 3, that means data is valid on the second rising edge.
It also means that the data is latshed on each falling edge of the clock signal.
See documentation
QuoteNSPI Driver, Native SPI Support, V3.1 (2011-11-14), page 6, Figure 10: SPI_Mode_3
Unfortunatley the signal is not conform with specification because the data on the PicoCOM4 is not latched on the falling edge but instead on the rising edge. this chauses a malfunction of our SPI chip MCP4822 application.
Please help us to solve the problem quickly.
Hai there,
I have tried the setting
with no success. The PCS0 line stays at zero. I would expect it to be high and getting active low.
Can you reconstruct the behavior I am observing?
What is about the documentation content in the PicoCOM device driver V1.2 page 8?
It says pin 29 is an input.
Can this be the reason that it not works?
We are migrating our application to use PicoCOM4 as a replacement of the PicoCOM2.
Our application works with the PicoCOM2 modul as expected.
Testing the same application on the PicoCOM4 the SPI-interface does not operate the chip select pin (PIN29 =PCS0) of the SPI-bus interface.
The SPI-driver version is V2.5, the Hardware version is V1.3
According to the documentation
QuoteNative SPI Support Version 1.3 (2011-11-14) page 11
pin 29 should be driven by the SPI-driver.
But looking into the documentation
QuotePicoCOM Device Driver Version V1.2 (2012-01-24) page 8
pin 29 is capable as a input terminal only. This contradicts with the information in SPI-driver documentation.
What can I do to make the pin 29 (PCS0) work?
Is there an error in the documentation?
here is my SPI configuration:
There was an entry
in the SPIController0 setting using the PicoCOM2, that activaded the chip select function.
Where is it controlled now? The above documentation does not reference to such an option.
Can I access /drive pin 29 (PCS0)?
Regards Jörg
We are replacing PicoCOM2 with a PicoCOM4 modul.
The problem is that something can be written to the port but not read back, which is required to protect other pins from manupulation.
Thererfore we need to read the port prior a pin is written to.
It did work using the PicoCOM2.
Because the specific ports are mulitplexed with SD/MMC, I have disabled also the SDBus driver, the SD driver und the MMC driver. I still can not read from pin 36 or 37 even when the LED's on those pin on our application board are on.
In our application we use the Pins 36, 37, 38 and 39 as outputs.
The DIO is configured the following way:
Our system info:
Board: PicoCOM4, HW: 1.30, SN: 000551040FA3, CPU: 534 MHz
Firmware: Eboot: V1.6, Nboot: PC425, Kernel: 1.05 -Build Dec 14 2011
What went wrong? What is missing? Can anyone quickly help please?
Regards Jörg
I have solved the problem.
The PicoCOM4 did not drive the VEE control line to high, resulting in a black display when switched on. This error was not present when the modul was inserted in the starter kit. To get the PicoCOM4 to work one have to enable the contrast control of the graphic driver
Quotereg set value contrastenable dword 1
.
kind regards
The following graphic display configuration files (downloaded from <!-- m --><a class="postlink" href="http://www.picocom.de">http://www.picocom.de</a><!-- m -->) are working with our display Bolymin BT057DBNHW using the PicoCOM2 on our motherboard design:
AM640480GHTNQW_.txt; ET057010DHU_.txt; G104VN01_.txt; LTD104_.txt; NL6448_.txt; TCG075VGLBA_.txt; TCG104_.txt; TX14D14VM_.txt; UMSH8004MD_.txt; UMSH8089_.txt; UMSH8227MD_.txt
These files do not work at all (black screen) using the PicoCOM4.
Hai,
in the mean time I have solved the problem of accessing the serial USB port resource from the target application.
The problem was, that one must initialise a first read of to the interface before accessing the serial interrupt service of the usb driver in a normal way.
kind regads
We are tranfering from PicoCOM2 to PicoCOM4.
Therefore I am testing a PicoCOM4 modul on our mother board design.
After uploading the latest kernel NKPC4_CORE_CF35_120119 my TFT VGA display does some thing (1/2 black and the other half is white).
Using the DCU-Term the modul promts with NetDCU Config utility.
The display settings text file, that worked on PicoCOM2 (valid for PicoCOM2/6), is now send to the PicoCOM4.
The result is a black screen. I have tried all files that worked previously with the PicoCOM2, but none is working with the PicoCOM4.
Can you give advise please? What went wrong?
Thank's, it works on my Windows 7 system.
We would like to use the USB-connection as a serial interface to communicate to the target.
For XP we have used device driver installation instruction to acitvate the serial port via USB, that was finaly recognied by the operating system.
Is there a serial device driver for Windows 7 64-Bit PC's available similar to the one that exists for XP?
If the ini-file is used, what needs to be changed that the device is going to be recognised by Winwos 7?
Thank you. I have found the active COM pot in HLKM\Drivers\Active\XX.
Q1: With our application I can not open the new port. Why?
Q2: Do you have a test application to check the operation of the new port?
Q3: Why can the virtual COM port on the PC-Side not be opend?
