Use Case C - Extended Webserver - getting started
- Former user (Deleted)
What's to be setup for use case C loadable firmware
Hardware Requirements
- NXHX 90-JTAG evaluation board or netX 90 design with external SQI Flash
- NXHX-SDRSPM SDRAM extension or SDRAM connected to netX 90 via the HIF interface
Flash Layout
The following data must be programmed into the internal flash memories of netX 90. netX STUDIO integrated flasher tool can be used for this task.
Erase all memories INTFLASH01, INTFLASH2 and Serial Flash (SQI) before.
- HW config with SQI Flash and SDRAM enabled
*.hwc file - offset 0x0000 INTFLASH0 - FDL for use case C - "FDL_NXHX90-JTAG_7833000r3_20000_ProductionTemplate_UseCaseC.fdl"
*.fdl file - offset 0x2000 INTFLASH0 - loadable firmware LFW EthernetIP with extended webserver - X090H001.nxi
*.nxi file - offset 0x3000 INTFLASH01 - user application
*.nai file - offset 0x0000 INTFLASH2 (this may be automatically programmed into the flash by the debugger, it is not necessary to use the flash programming tool explicitely)
- after initial setup of the device, the creation of the Filesystem must be triggered by the application with system mailbox service "HIL_FORMAT_REQ"
refer to netX Dual-Port Memory packet-based services netX 90 4000 4100 API.pdf
This is not necessary at every system start. The LFW does not create a filesystem, it expect a filesystem is present.
The PC utility netHOST can be used to send the HIL_FORMAT_REQ command through the UART Marshaller, or the mailbox packet can be send in the user application code.- Option 1) - using netHOST utility to send HIL_FORMAT_REQ mailbox packet using option
HIL_FORMAT_REQ_DATA_FLAGS_FULLFORMAT
- option 2) sending the HIL_FORMAT_REQ packet inside the user application
memset(&tPkt,0,8+sizeof(tPkt.tHeader));
tPkt.tHeader.ulCmd=0x1ED6; // HIL_FORMAT_REQ
tPkt.tHeader.ulDest=0x00; // send to system channel
tPkt.tHeader.ulLen=8;Pkt.abData[0]=0x01 // HIL_FORMAT_REQ_DATA_FLAGS_FULLFORMAT
// Pkt.abData can be left 0x00 for a quick format
Pkt_SendPacket(hSysChannel,&tPkt,1,100);
- Option 1) - using netHOST utility to send HIL_FORMAT_REQ mailbox packet using option
- in order to be able to use the webbased filemanager_gui, a file named "fileman" (no extension, filesize >0) must be downloaded into PORT1, using the netHOST utility
Interaction between Application and Firmware
- Application has to
open DPM commuinication channel 0 - Protocol stack
- open DPM commuinication channel 1 - Etherent interface
- configure protocol stack using the mailbox packet interface (this is necessary to start the TCP/IP stack)
- send REGISTER_APP_REQ in channel 1
- send WEBIF_REGISTER_REQ in channel 1
- now the application receives "WEBIF_HANDLE_HTTP_REQUEST_IND" and other indications in channel 1, when webcontent is requested from a remote client
- this must be answered with WEBIF_GENERATE_HTTP_RESPONSE_REQ etc.
URL Mapping
The following table describes the available resources and API according to the use cases.
URL | /webif | /netx/diag | /netx/npx | /files | /netx/firmware | /netx/reset | /netx | /netx/filemanager | /netx/filemanager_gui |
Use Case A | default / | ||||||||
Use Case B | default / | ||||||||
Use Case C | default / | ||||||||
Use Case C with netPROXY | default / |
The root "/" give a different resource according the use case (for use case C it makes a redirection to /files, for use case A and B it makes a redirection to /webif). If a scripts or an application uses an API provided over the WebIf module, the "/webif" URL shall be used in order to be portable between the use cases.
Documentation
- DPM Manual Packet Services: Packet-based services (netX 90/4000/4100)
- Webserver Interface Manual: Web server API
- Web Interface Manual: Web interface - Protocol API
- Socket Interface Manual: Socket Packet Interface API
-
Page:
-
Page:
-
Page:
-
Page:
-
Page:
-
Page:
-
Page:
-
Page:
-
Page:
-
Page:
-
Page:
-
Page:
-
Page:
-
Page:
-
Page: