TCPIP Stack Help
TCPIP Stack Help
1
1 1
3 7
56 56 57
58 59
59 59 60 60 61 61 62 62
Getting Started
Hardware Setup Daughter Boards PICDEM.net 2 PIC18 Explorer Explorer 16 and PIC32 Starter Kit PIC24FJ256DA210 Dev Board Programming and First Run Configure your WiFi Access Point Connecting to the Network
64
64 64 65 67 68 71 71 72 74 ii
Uploading Web Pages Accessing the Demo Application Configuring WiFi Security
74 75 76
Demo Information
Demo Compatibility Table Available Demos Demo App TCPIP Demo App Features by Hardware Platform Demo Modules Web Page Demos E-mail (SMTP) Demo Generic TCP Client Generic TCP Server Ping (ICMP) Demo SNMP Server (Agent) UART-to-TCP Bridge Zero Configuration (ZeroConf) Internet Bootloader Bootloader Design Using the Bootloader WebVend Internet Radio WiFi Console Standalone Commands iwconfig Commands ifconfig Commands iwpriv Commands iperf Example WiFi EZConfig Demo App MDD Google PowerMeter Energy Monitoring
79
79 83 83 83 84 84 93 94 97 98 100 116 116 117 118 120 123 123 124 124 125 126 127 128 130 132 132 133
134
134 134 134 135 iii
Microchip TCP/IP Stack Help Main File Initialization Main Loop Cooperative Multitasking RTOS 135 135 135 136 138
139
139 139 139 140 141 143 143 144 144 145 146 147 148 149 149 149 150 151 151
Stack API
Announce Stack Members AnnounceIP Function DiscoveryTask Function ARP Public Members ARPResolve Function ARPIsResolved Function ARPDeRegisterCallbacks Function ARPRegisterCallbacks Function ARPSendPkt Function arp_app_callbacks Structure
152
152 153 153 153 154 154 155 156 156 157 157 158 iv
Microchip TCP/IP Stack Help ARP_REQ Macro ARP_RESP Macro MAX_REG_APPS Macro Stack Members ARPInit Function ARPProcess Function Internal Members ARPPut Function SwapARPPacket Function ARP_OPERATION_REQ Macro ARP_OPERATION_RESP Macro HW_ETHERNET Macro ARP_IP Macro Cache Variable reg_apps Variable Types ARP_PACKET Structure BSD Sockets Public Members accept Function AF_INET Macro bind Function BSDSocket Structure closesocket Function connect Function gethostname Function in_addr Structure INADDR_ANY Macro INVALID_TCP_PORT Macro IP_ADDR_ANY Macro IPPROTO_IP Macro IPPROTO_TCP Macro IPPROTO_UDP Macro listen Function recv Function recvfrom Function send Function sendto Function SOCK_DGRAM Macro SOCK_STREAM Macro sockaddr Structure SOCKADDR Type 158 158 158 159 159 159 160 161 161 162 162 162 162 162 163 163 163 164 165 166 167 167 167 168 168 169 170 170 171 171 171 171 171 172 172 173 174 174 175 175 175 176 v
Microchip TCP/IP Stack Help sockaddr_in Structure SOCKADDR_IN Type socket Function SOCKET Type SOCKET_CNXN_IN_PROGRESS Macro SOCKET_DISCONNECTED Macro SOCKET_ERROR Macro Stack Members BerkeleySocketInit Function Internal Members BSD_SCK_STATE Enumeration BSDSocketArray Variable gAutoPortNumber Variable HandlePossibleTCPDisconnection Function DNS Public Members DNSBeginUsage Function DNSEndUsage Function DNSResolve Function DNSResolveROM Function DNSIsResolved Function DNS_TYPE_A Macro DNS_TYPE_MX Macro Internal Members DNSPutString Function DNSPutROMString Function DNS_PORT Macro DNS_TIMEOUT Macro DNSHostName Variable DNSHostNameROM Variable Flags Variable RecordType Variable ResolvedInfo Variable smDNS Variable DNS_HEADER Structure DNSDiscardName Function Dynamic DNS Client Public Members DDNS_POINTERS Structure DDNS_SERVICES Enumeration DDNS_STATUS Enumeration 176 176 177 177 177 178 178 178 178 179 179 180 180 180 181 181 182 182 183 183 184 184 185 185 186 186 187 187 187 187 188 188 188 188 189 189 190 190 191 192 192
vi
Microchip TCP/IP Stack Help DDNSClient Variable DDNSForceUpdate Function DDNSGetLastIP Function DDNSGetLastStatus Function DDNSSetService Function Stack Members DDNSInit Function DDNSTask Function Internal Members bForceUpdate Variable ddnsServiceHosts Variable ddnsServicePorts Variable dwUpdateAt Variable lastKnownIP Variable lastStatus Variable _checkIpSrvrResponse Variable _updateIpSrvrResponse Variable DDNS_CHECKIP_SERVER Macro DDNS_DEFAULT_PORT Macro Hashes Public Members HashAddData Function HashAddROMData Function MD5Calculate Function MD5Initialize Function SHA1Calculate Function SHA1Initialize Function HASH_SUM Structure Stack Members MD5AddROMData Function SHA1AddROMData Function SHA1AddData Function MD5AddData Function Internal Members _MD5_k Variable _MD5_r Variable lastBlock Variable HASH_TYPE Enumeration SHA1HashBlock Function MD5HashBlock Function Helpers 193 193 194 194 194 195 195 195 196 197 197 197 197 197 198 198 198 198 199 199 199 200 200 201 202 202 202 203 204 204 205 205 206 206 207 207 207 207 208 209 209
vii
Microchip TCP/IP Stack Help Public Members Base64Decode Function Base64Encode Function btohexa_high Function btohexa_low Function CalcIPBufferChecksum Function CalcIPChecksum Function ExtractURLFields Function FormatNetBIOSName Function GenerateRandomDWORD Function hexatob Function leftRotateDWORD Function leftRotateDWORD Macro Replace Function ROMStringToIPAddress Function ROMStringToIPAddress Macro stricmppgm2ram Function StringToIPAddress Function strupr Function strnchr Function swapl Function swaps Function uitoa Function ultoa Function UnencodeURL Function Functions LFSRRand Function LFSRSeedRand Function Variables dwLFSRRandSeed Variable HTTP2 Server Features Dynamic Variables Form Processing Authentication Cookies Compression Public Members curHTTP Variable HTTP_CONN Structure HTTP_IO_RESULT Enumeration HTTP_READ_STATUS Enumeration 210 211 211 212 212 213 213 214 217 217 218 218 219 219 220 221 221 221 222 222 223 223 224 224 225 225 225 226 227 227 227 228 228 230 233 235 235 236 237 237 238 238 viii
Microchip TCP/IP Stack Help HTTPCheckAuth Function HTTPExecuteGet Function HTTPExecutePost Function HTTPGetArg Function HTTPGetROMArg Function HTTPNeedsAuth Function HTTPPrint_varname Function HTTPReadPostName Function HTTPReadPostPair Macro HTTPReadPostValue Function HTTPURLDecode Function sktHTTP Macro Stack Members HTTPInit Function HTTPServer Function Internal Members curHTTPID Variable HTTP_CACHE_LEN Macro HTTP_FILE_TYPE Enumeration HTTP_MAX_DATA_LEN Macro HTTP_MAX_HEADER_LEN Macro HTTP_MIN_CALLBACK_FREE Macro HTTP_PORT Macro HTTP_STATUS Enumeration HTTP_STUB Structure HTTP_TIMEOUT Macro httpContentTypes Variable httpFileExtensions Variable HTTPHeaderParseAuthorization Function HTTPHeaderParseContentLength Function HTTPHeaderParseCookie Function HTTPHeaderParseLookup Function HTTPIncFile Function HTTPLoadConn Function HTTPMPFSUpload Function HTTPProcess Function HTTPReadTo Function HTTPRequestHeaders Variable HTTPResponseHeaders Variable HTTPS_PORT Macro HTTPSendFile Function httpStubs Variable 238 239 240 241 242 242 243 244 245 245 246 247 247 247 248 248 249 250 250 251 251 251 251 251 252 253 253 253 253 254 254 255 255 256 256 257 257 258 258 258 259 259 ix
Microchip TCP/IP Stack Help SM_HTTP2 Enumeration smHTTP Macro RESERVED_HTTP_MEMORY Macro ICMP Public Members ICMPBeginUsage Function ICMPSendPing Function ICMPSendPingToHost Function ICMPSendPingToHostROM Function ICMPGetReply Function ICMPEndUsage Function ICMPSendPingToHostROM Macro Internal Members ICMPProcess Function ICMPFlags Variable ICMP_PACKET Structure ICMPState Variable ICMP_TIMEOUT Macro ICMPTimer Variable StaticVars Variable wICMPSequenceNumber Variable MPFS2 Public Members MPFS_HANDLE Type MPFS_INVALID Macro MPFS_INVALID_HANDLE Macro MPFS_SEEK_MODE Enumeration MPFSClose Function MPFSFormat Function MPFSGet Function MPFSGetArray Function MPFSGetBytesRem Function MPFSGetEndAddr Function MPFSGetFilename Function MPFSGetFlags Function MPFSGetID Function MPFSGetLong Function MPFSGetMicrotime Function MPFSGetPosition Function MPFSGetSize Function MPFSGetStartAddr Function 259 260 260 260 261 261 262 262 263 263 264 264 265 265 266 266 266 267 267 267 268 268 269 270 270 270 270 271 271 272 272 273 273 274 274 275 275 276 276 276 277
Microchip TCP/IP Stack Help MPFSGetTimestamp Function MPFSOpen Function MPFSOpenID Function MPFSOpenROM Function MPFSPutArray Function MPFSSeek Function MPFSPutEnd Function Stack Members MPFSInit Function Internal Members isMPFSLocked Variable lastRead Variable MAX_FILE_NAME_LEN Macro MPFS_PTR Type MPFS_STUB Structure MPFS_WRITE_PAGE_SIZE Macro MPFS2_FLAG_HASINDEX Macro MPFS2_FLAG_ISZIPPED Macro MPFSStubs Variable MPFSTell Macro ReadProgramMemory Function _LoadFATRecord Function _Validate Function MPFS_FAT_RECORD Structure fatCache Variable fatCacheID Variable numFiles Variable MPFS_INVALID_FAT Macro NBNS Stack Members NBNSGetName Function NBNSPutName Function NBNSTask Function NBNS_HEADER Structure NBNS_PORT Macro Performance Tests Stack Members TCPPerformanceTask Function UDPPerformanceTask Function Internal Members TCPRXPerformanceTask Function 277 278 278 279 279 280 280 281 281 281 282 283 283 283 283 284 284 284 284 285 285 285 286 286 286 287 287 287 287 288 288 289 289 290 290 290 290 291 291 292 292
xi
Microchip TCP/IP Stack Help TCPTXPerformanceTask Function PERFORMANCE_PORT Macro RX_PERFORMANCE_PORT Macro TX_PERFORMANCE_PORT Macro SMTP Client Examples Short Message Long Message Public Members SMTP_CONNECT_ERROR Macro SMTP_POINTERS Structure SMTP_RESOLVE_ERROR Macro SMTP_SUCCESS Macro SMTPBeginUsage Function SMTPClient Variable SMTPEndUsage Function SMTPFlush Function SMTPIsBusy Function SMTPIsPutReady Function SMTPPut Function SMTPPutArray Function SMTPPutDone Function SMTPPutROMArray Function SMTPPutROMString Function SMTPPutString Function SMTPSendMail Function Stack Members SMTPTask Function Internal Members CRPeriod Variable FindEmailAddress Function FindROMEmailAddress Function MySocket Variable PutHeadersState Variable ResponseCode Variable RXParserState Variable SMTP_PORT Macro SMTP_SERVER_REPLY_TIMEOUT Macro SMTPFlags Variable SMTPServer Variable SMTPState Variable TransportState Variable 293 293 293 294 294 294 294 295 297 298 298 300 300 300 301 301 301 302 302 303 303 304 304 305 305 306 306 307 307 308 308 309 309 309 310 310 311 311 311 311 312 313 xii
Reboot Stack Members RebootTask Function REBOOT_PORT Macro REBOOT_SAME_SUBNET_ONLY Macro SNMP Public Members GENERIC_TRAP_NOTIFICATION_TYPE Enumeration VENDOR_SPECIFIC_TRAP_NOTIFICATION_TYPE Enumeration SNMP_ACTION Enumeration COMMUNITY_TYPE Enumeration SNMP_VAL Union TRAP_INFO Structure gSendTrapFlag Variable gSetTrapSendFlag Variable gGenericTrapNotification Variable gSpecificTrapNotification Variable gOIDCorrespondingSnmpMibID Variable SNMPSendTrap Function SNMPValidateCommunity Function SNMPNotify Function SNMPSetVar Function SNMPGetVar Function SNMPIsNotifyReady Function SNMPNotifyPrepare Function SNMPGetNextIndex Function SNMP_ID Type SNMP_INDEX Type SNMP_COMMUNITY_MAX_LEN Macro OID_MAX_LEN Macro SNMP_START_OF_VAR Macro SNMP_END_OF_VAR Macro SNMP_INDEX_INVALID Macro TRAP_TABLE_SIZE Macro TRAP_COMMUNITY_MAX_LEN Macro NOTIFY_COMMUNITY_LEN Macro Internal Members _SNMPDuplexInit Function _SNMPGet Function _SNMPGetTxOffset Macro _SNMPPut Function
314 314 314 315 315 315 317 319 319 319 320 320 321 321 321 322 322 322 322 323 323 324 325 325 326 327 327 327 328 328 328 328 329 329 329 329 330 333 333 333 333
xiii
Microchip TCP/IP Stack Help _SNMPSetTxOffset Macro AGENT_NOTIFY_PORT Macro appendZeroToOID Variable ASN_INT Macro ASN_NULL Macro ASN_OID Macro DATA_TYPE Enumeration DATA_TYPE_INFO Structure DATA_TYPE_TABLE_SIZE Macro dataTypeTable Variable FindOIDsInRequest Function GET_BULK_REQUEST Macro GET_NEXT_REQUEST Macro GET_REQUEST Macro GET_RESPONSE Macro hMPFS Variable INDEX_INFO Union IS_AGENT_PDU Macro IS_ASN_INT Macro IS_ASN_NULL Macro IS_GET_NEXT_REQUEST Macro IS_GET_REQUEST Macro IS_GET_RESPONSE Macro IS_OCTET_STRING Macro IS_OID Macro GetDataTypeInfo Function IS_SET_REQUEST Macro IS_STRUCTURE Macro IS_TRAP Macro IsASNNull Function MIB_INFO Union OCTET_STRING Macro OID_INFO Structure PDU_INFO Structure reqVarErrStatus Structure SET_REQUEST Macro SetErrorStatus Function SNMP_AGENT_PORT Macro SNMP_BIB_FILE_NAME Macro SNMP_COUNTER32 Macro SNMP_ERR_STATUS Enumeration SNMP_GAUGE32 Macro 334 334 334 334 335 335 335 336 336 336 337 337 337 337 337 338 338 338 339 339 339 339 339 340 340 340 340 341 341 341 341 342 342 343 343 344 344 344 345 345 345 346 xiv
Microchip TCP/IP Stack Help SNMP_IP_ADDR Macro SNMP_NMS_PORT Macro SNMP_NOTIFY_INFO Structure SNMP_NSAP_ADDR Macro IsValidLength Function SNMP_OPAQUE Macro SNMP_STATUS Union SNMP_TIME_TICKS Macro SNMP_V1 Macro SNMP_V2C Macro SNMPAgentSocket Variable SNMPNotifyInfo Variable snmpReqVarErrStatus Variable SNMPRxOffset Variable SNMPStatus Variable SNMPTxOffset Variable STRUCTURE Macro TRAP Macro trapInfo Variable GetDataTypeInfo Function GetNextLeaf Function GetOIDStringByAddr Function GetOIDStringByID Function IsValidCommunity Function IsValidInt Function IsValidLength Function IsValidOID Function IsValidPDU Function IsValidStructure Function OIDLookup Function ProcessGetSetHeader Function ProcessHeader Function ProcessSetVar Function ProcessVariables Function ReadMIBRecord Function SNMPCheckIfPvtMibObjRequested Function Stack Members SNMPInit Function SNMPTask Function Functions getSnmpV2GenTrapOid Function ProcessGetBulkVar Function 346 347 347 347 348 348 348 348 349 349 349 349 350 350 350 350 350 351 351 351 351 352 352 352 352 353 353 353 353 354 354 355 355 355 356 356 357 357 357 358 359 359 xv
Microchip TCP/IP Stack Help ProcessGetNextVar Function ProcessGetVar Function ProcessSnmpv3MsgData Function SNMPGetExactIndex Function SNMPIdRecrdValidation Function SNMPIsValidSetLen Function Snmpv3AESDecryptRxedScopedPdu Function Snmpv3BufferPut Function Snmpv3FormulateEngineID Function Snmpv3GetAuthEngineTime Function Snmpv3GetBufferData Function Snmpv3InitializeUserDataBase Function Snmpv3MsgProcessingModelProcessPDU Function Snmpv3Notify Function Snmpv3ScopedPduProcessing Function Snmpv3TrapScopedpdu Function Snmpv3UserSecurityModelProcessPDU Function Snmpv3UsmAesEncryptDecryptInitVector Function Snmpv3UsmOutMsgAuthenticationParam Function Snmpv3ValidateEngineId Function Snmpv3ValidateSecNameAndSecLvl Function Snmpv3ValidateSecurityName Function Types INOUT_SNMP_PDU Enumeration SNMPNONMIBRECDINFO Structure SNMPV3MSGDATA Structure Variables getZeroInstance Variable gSNMPv3ScopedPduDataPos Variable gSNMPv3ScopedPduRequestBuf Variable gSNMPv3ScopedPduResponseBuf Variable msgSecrtyParamLenOffset Variable Macros IS_SNMPV3_AUTH_STRUCTURE Macro REPORT_RESPONSE Macro SNMP_MAX_MSG_SIZE Macro SNMP_V3 Macro SNTP Client Public Members SNTPGetUTCSeconds Function Stack Members SNTPClient Function 360 360 360 360 361 362 362 362 363 363 363 363 364 364 364 364 365 365 365 365 366 366 366 366 367 367 367 368 368 368 368 369 369 369 369 370 370 370 370 371 371 371 xvi
Microchip TCP/IP Stack Help Internal Members NTP_PACKET Structure dwLastUpdateTick Variable dwSNTPSeconds Variable NTP_EPOCH Macro NTP_FAST_QUERY_INTERVAL Macro NTP_QUERY_INTERVAL Macro NTP_REPLY_TIMEOUT Macro NTP_SERVER Macro NTP_SERVER_PORT Macro SSL Generating Server Certificates Public Members SSL_INVALID_ID Macro TCPAddSSLListener Function TCPSSLIsHandshaking Function TCPStartSSLClient Function TCPIsSSL Function SSLStartSession Function SSL_SUPPLEMENTARY_DATA_TYPES Enumeration SSL_PKEY_INFO Structure SSL_RSA_KEY_SIZE Macro SSL_RSA_CLIENT_SIZE Macro Stack Members SSL_STATE Enumeration SSLInit Function SSLPeriodic Function TCPRequestSSLMessage Function TCPSSLGetPendingTxSize Function TCPSSLHandleIncoming Function TCPSSLHandshakeComplete Function TCPSSLInPlaceMACEncrypt Function TCPSSLPutRecordHeader Function TCPStartSSLServer Function SSL_MIN_SESSION_LIFETIME Macro SSL_RSA_LIFETIME_EXTENSION Macro Internal Members CalculateFinishedHash Function GenerateHashRounds Function GenerateSessionKeys Function HSEnd Function HSGet Function 372 372 373 374 374 374 374 375 375 375 375 377 380 380 381 381 382 382 383 383 383 384 384 384 385 386 386 386 387 387 388 388 389 390 390 390 391 396 396 397 397 398 xvii
Microchip TCP/IP Stack Help HSGetArray Function HSGetWord Function HSPut Function HSPutArray Function HSPutROMArray Function HSPutWord Function HSStart Function isBufferUsed Variable isHashUsed Variable isStubUsed Variable masks Variable ptrHS Variable RESERVED_SSL_MEMORY Macro LoadOffChip Function SaveOffChip Function SM_SSL_RX_SERVER_HELLO Enumeration SSL_ALERT Macro SSL_ALERT_LEVEL Enumeration SSL_APPLICATION Macro SSL_BASE_BUFFER_ADDR Macro SSL_BASE_HASH_ADDR Macro SSL_BASE_KEYS_ADDR Macro SSL_BASE_SESSION_ADDR Macro SSL_BASE_STUB_ADDR Macro SSL_BUFFER Union SSL_BUFFER_SIZE Macro SSL_BUFFER_SPACE Macro SSL_CERT Variable SSL_CERT_LEN Variable SSL_CHANGE_CIPHER_SPEC Macro SSL_HANDSHAKE Macro SSL_HASH_SIZE Macro SSL_HASH_SPACE Macro SSL_KEYS Structure SSL_KEYS_SIZE Macro SSL_KEYS_SPACE Macro SSL_MESSAGES Enumeration SSL_RSA_EXPORT_WITH_ARCFOUR_40_MD5 Macro SSL_RSA_WITH_ARCFOUR_128_MD5 Macro SSL_SESSION Structure SSL_SESSION_SIZE Macro SSL_SESSION_SPACE Macro 398 399 399 400 401 401 401 402 402 402 403 403 403 403 404 404 405 405 405 406 406 406 406 406 407 407 407 408 408 408 408 408 409 409 410 410 410 411 411 411 412 412 xviii
Microchip TCP/IP Stack Help SSL_SESSION_STUB Structure SSL_SESSION_TYPE Enumeration SSL_STUB Structure SSL_STUB_SIZE Macro SSL_STUB_SPACE Macro SSL_VERSION Macro SSL_VERSION_HI Macro SSL_VERSION_LO Macro SSLBufferAlloc Function SSLBufferFree Function sslBufferID Variable SSLBufferSync Function SSLFinishPartialRecord Macro SSLFlushPartialRecord Macro sslHash Variable SSLHashAlloc Function SSLHashFree Function sslHashID Variable SSLHashSync Function sslKeys Variable sslKeysID Variable SSLKeysSync Function SSLMACAdd Function SSLMACBegin Function SSLMACCalc Function SSLRSAOperation Function sslRSAStubID Variable SSLRxAlert Function SSLRxAntiqueClientHello Function SSLRxCCS Function SSLRxClientHello Function SSLRxClientKeyExchange Function SSLRxFinished Function SSLRxHandshake Function SSLRxRecord Function SSLRxServerCertificate Function SSLRxServerHello Function sslSession Variable sslSessionID Variable SSLSessionMatchID Function SSLSessionMatchIP Function SSLSessionNew Function 412 413 413 414 414 415 415 415 415 416 416 417 417 417 418 418 418 419 419 420 420 420 421 421 421 421 422 422 423 423 424 424 425 425 426 426 427 427 428 428 428 429 xix
Microchip TCP/IP Stack Help sslSessionStubs Variable SSLSessionSync Function SSLSessionUpdated Macro sslSessionUpdated Variable SSLStartPartialRecord Function sslStub Variable SSLStubAlloc Function SSLStubFree Function sslStubID Variable SSLStubSync Function SSLTerminate Function SSLTxCCSFin Function SSLTxClientHello Function SSLTxClientKeyExchange Function SSLTxMessage Function SSLTxRecord Function SSLTxServerCertificate Function SSLTxServerHello Function SSLTxServerHelloDone Function Files SSLClientSize.h TCP Public Members INVALID_SOCKET Macro UNKNOWN_SOCKET Macro TCP_ADJUST_GIVE_REST_TO_RX Macro TCP_ADJUST_GIVE_REST_TO_TX Macro TCP_ADJUST_PRESERVE_RX Macro TCP_ADJUST_PRESERVE_TX Macro TCP_OPEN_IP_ADDRESS Macro TCP_OPEN_NODE_INFO Macro TCP_OPEN_RAM_HOST Macro TCP_OPEN_ROM_HOST Macro TCP_OPEN_SERVER Macro TCPAdjustFIFOSize Function TCPConnect Macro TCPClose Function TCPDiscard Function TCPDisconnect Function TCPFind Macro TCPFindArray Macro TCPFindArrayEx Function 429 430 430 430 431 431 432 432 433 433 433 434 434 435 435 436 436 437 438 438 438 439 440 442 442 442 442 442 443 443 443 443 444 444 444 445 445 446 446 447 447 447 xx
Microchip TCP/IP Stack Help TCPFindEx Function TCPFindROMArray Macro TCPFindROMArrayEx Function TCPFlush Function TCPGet Function TCPGetArray Function TCPGetRemoteInfo Function TCPGetRxFIFOFree Function TCPGetRxFIFOFull Macro TCPGetTxFIFOFree Macro TCPGetTxFIFOFull Function TCPIsConnected Function TCPIsGetReady Function TCPIsPutReady Function TCPListen Macro TCPOpen Function TCPPeek Function TCPPeekArray Function TCPPut Function TCPPutArray Function TCPPutROMArray Function TCPPutROMString Function TCPPutString Function TCPRAMCopy Function TCPRAMCopyROM Function TCPWasReset Function Stack Members SOCKET_INFO Structure TCB Structure TCB_STUB Structure TCP_SOCKET Type TCP_STATE Enumeration TCPInit Function TCPProcess Function TCPTick Function TCPSSLDecryptMAC Function TCPStartSSLClientEx Function Internal Members ACK Macro CloseSocket Function FIN Macro FindMatchingSocket Function 448 449 449 450 450 451 451 452 452 453 453 453 454 454 455 455 457 457 458 458 459 459 460 460 461 462 462 463 464 465 466 466 467 468 468 469 469 470 472 472 472 473 xxi
Microchip TCP/IP Stack Help HandleTCPSeg Function hCurrentTCP Variable LOCAL_PORT_END_NUMBER Macro LOCAL_PORT_START_NUMBER Macro MyTCB Variable MyTCBStub Variable PSH Macro RST Macro SendTCP Function SENDTCP_KEEP_ALIVE Macro SENDTCP_RESET_TIMERS Macro SwapTCPHeader Function SYN Macro SyncTCB Function SyncTCBStub Macro SYNQueue Variable TCBStubs Variable TCP_AUTO_TRANSMIT_TIMEOUT_VAL Macro TCP_WINDOW_UPDATE_TIMEOUT_VAL Macro TCP_CLOSE_WAIT_TIMEOUT Macro TCP_DELAYED_ACK_TIMEOUT Macro TCP_FIN_WAIT_2_TIMEOUT Macro TCP_HEADER Structure TCP_KEEP_ALIVE_TIMEOUT Macro TCP_MAX_RETRIES Macro TCP_MAX_SEG_SIZE_RX Macro TCP_MAX_SEG_SIZE_TX Macro TCP_MAX_SYN_RETRIES Macro TCP_MAX_UNACKED_KEEP_ALIVES Macro TCP_OPTIMIZE_FOR_SIZE Macro TCP_OPTIONS Structure TCP_OPTIONS_END_OF_LIST Macro TCP_OPTIONS_MAX_SEG_SIZE Macro TCP_OPTIONS_NO_OP Macro TCP_SOCKET_COUNT Macro TCP_START_TIMEOUT_VAL Macro TCP_SYN_QUEUE Structure TCP_SYN_QUEUE_MAX_ENTRIES Macro TCP_SYN_QUEUE_TIMEOUT Macro URG Macro Variables NextPort Variable 473 474 474 474 474 475 475 475 475 476 476 476 477 477 477 477 477 478 478 478 478 479 479 480 480 480 481 481 481 481 482 482 482 482 483 483 483 484 484 484 484 484 xxii
TFTP Public Members TFTPClose Macro TFTPCloseFile Function TFTPGet Function TFTPGetError Macro TFTPIsFileClosed Function TFTPIsFileOpened Function TFTPIsFileOpenReady Macro TFTPIsGetReady Function TFTPIsOpened Function TFTPIsPutReady Function TFTPOpen Function TFTPOpenFile Function TFTPOpenROMFile Function TFTPPut Function TFTP_ACCESS_ERROR Enumeration TFTP_FILE_MODE Enumeration TFTP_RESULT Enumeration TFTPGetUploadStatus Function TFTPUploadFragmentedRAMFileToHost Function TFTPUploadRAMFileToHost Function TFTP_CHUNK_DESCRIPTOR Structure TFTP_UPLOAD_COMPLETE Macro TFTP_UPLOAD_CONNECT Macro TFTP_UPLOAD_CONNECT_TIMEOUT Macro TFTP_UPLOAD_GET_DNS Macro TFTP_UPLOAD_HOST_RESOLVE_TIMEOUT Macro TFTP_UPLOAD_RESOLVE_HOST Macro TFTP_UPLOAD_SEND_DATA Macro TFTP_UPLOAD_SEND_FILENAME Macro TFTP_UPLOAD_SERVER_ERROR Macro TFTP_UPLOAD_WAIT_FOR_CLOSURE Macro Stack Members TFTP_ARP_TIMEOUT_VAL Macro TFTP_GET_TIMEOUT_VAL Macro TFTP_MAX_RETRIES Macro Internal Members MutExVar Variable TFTP_BLOCK_SIZE Macro TFTP_BLOCK_SIZE_MSB Macro TFTP_CLIENT_PORT Macro
489 490 492 492 493 493 494 494 495 495 496 496 497 498 498 499 499 499 500 500 501 502 502 503 503 503 503 504 504 504 504 504 505 505 505 506 506 506 507 508 508 508 xxiii
Microchip TCP/IP Stack Help TFTP_OPCODE Enumeration TFTP_SERVER_PORT Macro TFTP_STATE Enumeration _tftpError Variable _tftpFlags Variable _tftpRetries Variable _TFTPSendAck Function _TFTPSendFileName Function _TFTPSendROMFileName Function _tftpSocket Variable _tftpStartTick Variable _tftpState Variable smUpload Variable uploadChunkDescriptor Variable uploadChunkDescriptorForRetransmit Variable vUploadFilename Variable vUploadRemoteHost Variable wUploadChunkOffset Variable wUploadChunkOffsetForRetransmit Variable Tick Public Members TICK Type TICK_HOUR Macro TICK_MINUTE Macro TICK_SECOND Macro TickConvertToMilliseconds Function TickGet Function TickGetDiv256 Function TickGetDiv64K Function Stack Functions TickInit Function TickUpdate Function Internal Members dwInternalTicks Variable GetTickCopy Function TICKS_PER_SECOND Macro vTickReading Variable UDP Public Members INVALID_UDP_PORT Macro INVALID_UDP_SOCKET Macro 508 509 509 509 509 510 510 510 511 511 511 511 511 512 512 512 512 513 513 513 514 514 515 515 515 515 516 516 517 517 517 518 518 518 519 519 519 520 521 522 522
xxiv
Microchip TCP/IP Stack Help UDP_SOCKET Type UDPOpenEx Function UDPOpen Macro UDPClose Function UDPDiscard Function UDPFlush Function UDPGet Function UDPGetArray Function UDPIsGetReady Function UDPIsPutReady Function UDPPut Function UDPPutArray Function UDPPutROMArray Function UDPPutROMString Function UDPPutString Function UDPSetRxBuffer Function UDPSetTxBuffer Function UDPIsOpened Function UDP_OPEN_IP_ADDRESS Macro UDP_OPEN_NODE_INFO Macro UDP_OPEN_RAM_HOST Macro UDP_OPEN_ROM_HOST Macro UDP_OPEN_SERVER Macro Stack Members UDPInit Function UDPProcess Function UDPTask Function Internal Members activeUDPSocket Variable FindMatchingSocket Function LastPutSocket Variable LOCAL_UDP_PORT_END_NUMBER Macro LOCAL_UDP_PORT_START_NUMBER Macro SocketWithRxData Variable UDP_HEADER Structure UDP_PORT Type UDP_SOCKET_INFO Structure UDPRxCount Variable UDPSocketInfo Variable UDPTxCount Variable wGetOffset Variable wPutOffset Variable 522 523 524 525 525 526 526 527 527 528 528 529 529 530 530 531 531 532 532 532 533 533 533 533 534 534 535 535 536 536 537 537 537 537 538 538 538 539 539 539 539 540 xxv
Wi-Fi API
Wi-Fi Connection Profile Connection Profile Public Members WF_CPCreate Function WF_CPDelete Function WF_CPGetAdHocBehavior Function WF_CPGetBssid Function WF_CPGetDefaultWepKeyIndex Function WF_CPGetElements Function WF_CPGetIds Function WF_CPGetNetworkType Function WF_CPGetSecurity Function WF_CPGetSsid Function WF_CPSetAdHocBehavior Function WF_CPSetBssid Function WF_CPSetDefaultWepKeyIndex Function WF_CPSetElements Function WF_CPSetNetworkType Function WF_CPSetSecurity Function WF_CPSetSsid Function WFCPElementsStruct Structure Connection Profile Internal Members LowLevel_CPGetElement Function LowLevel_CPSetElement Function Wi-Fi Connection Algorithm Connection Algorithm Public Members WF_CAGetBeaconTimeout Function WF_CAGetBeaconTimeoutAction Function WF_CAGetChannelList Function WF_CAGetConnectionProfileList Function WF_CAGetDeauthAction Function WF_CAGetElements Function WF_CAGetEventNotificationAction Function WF_CAGetListenInterval Function WF_CAGetListRetryCount Function WF_CAGetMaxChannelTime Function WF_CAGetMinChannelTime Function WF_CAGetProbeDelay Function
541
544 544 545 546 546 547 547 548 548 549 550 551 551 552 552 553 553 554 555 555 556 557 557 558 558 559 560 561 561 562 562 563 563 564 564 565 565 xxvi
Microchip TCP/IP Stack Help WF_CAGetRssi Function WF_CAGetScanCount Function WF_CAGetScanType Function WF_CASetBeaconTimeout Function WF_CASetBeaconTimeoutAction Function WF_CASetChannelList Function WF_CASetConnectionProfileList Function WF_CASetDeauthAction Function WF_CASetElements Function WF_CASetEventNotificationAction Function WF_CASetListenInterval Function WF_CASetListRetryCount Function WF_CASetMaxChannelTime Function WF_CASetMinChannelTime Function WF_CASetProbeDelay Function WF_CASetRssi Function WF_CASetScanCount Function WF_CASetScanType Function WFCAElementsStruct Structure Connection Algorithm Internal Members LowLevel_CAGetElement Function LowLevel_CASetElement Function SetEventNotificationMask Function Wi-Fi Connection Manager Connection Manager Public Members WF_CMConnect Function WF_CMDisconnect Function WF_CMGetConnectionState Function WF_CMInfoGetFSMStats Function Wi-Fi Scan Scan Public Members WF_Scan Function WF_ScanGetResult Function Wi-Fi Tx Power Control Tx Power Control Public Members WF_TxPowerGetMinMax Function WF_TxPowerSetMinMax Function WF_TxPowerGetFactoryMax Function Wi-Fi Power Save Power Save Public Members WF_GetPowerSaveState Function 566 566 567 567 568 569 569 570 570 571 571 572 573 573 574 574 575 575 576 577 578 578 579 580 580 580 581 581 582 582 582 583 584 584 584 585 585 586 586 587 587 xxvii
Microchip TCP/IP Stack Help WF_HibernateEnable Function WF_PsPollDisable Function WF_PsPollEnable Function Power Save Internal Members SendPowerModeMsg Function SetPowerSaveState Function Wi-Fi Miscellaneous Wi-Fi Miscellaneous Public Members WF_GetDeviceInfo Function WF_GetMacAddress Function WF_GetMacStats Function WF_GetMultiCastFilter Function WF_GetRegionalDomain Function WF_GetRtsThreshold Function WF_SetMacAddress Function WF_SetMultiCastFilter Function WF_SetRegionalDomain Function WF_SetRtsThreshold Function tWFDeviceInfoStruct Structure WFMacStatsStruct Structure WF_ProcessEvent Access Point Compatibility WiFi Tips and Tricks Hot Topics 588 589 589 590 590 590 591 591 592 592 593 593 594 595 595 596 596 597 597 598 599 601 603 604
Index
xxviii
1 Introduction
Welcome to the Microchip TCP/IP Stack! The Microchip TCP/IP Stack provides a foundation for embedded network applications by handling most of the interaction required between the physical network port and your application. It includes modules for several commonly used application layers, including HTTP for serving web pages, SMTP for sending e-mails, SNMP for providing status and control, Telnet, TFTP, Serial-to-Ethernet and much more. In addition, the stack includes light-weight and high-performance implementations of the TCP and UDP transport layers, as well as other supporting modules such as IP, ICMP, DHCP, ARP, and DNS. This help file serves two purposes. The first is to be a guide for first-time users of the TCP/IP Stack. The Getting Started section begins a series of pages to help you become familiar with the stack and configure it for use on a Microchip development board. The second purpose is to serve as a programmer's reference guide to the features and APIs available in the TCP/IP Stack. Updates The latest version of the Microchip TCP/IP Stack is always available at http://www.microchip.com/tcpip. New features are constantly being added, so check there periodically for updates and bug fixes.
Several demonstration projects are installed into the TCPIP directory in the default Microchip Solutions v20xx-xx-xx directory. In your projects, you may wish to write your application code in a project folder located in the same place as the demo project folders. For more information about specific demos, see the list of demo projects ( see page 83) in this help file. These project folders may contain additional subdirectories: A Configs subdirectory will contain alternative copies of the TCPIPConfig.h and HardwareProfile.h configuration files, pre-configured to work with different demo boards. The default copies of these files in the demo folder will include one of these alternative files based on a macro defined in the demo project. An SSLKeys subdirectory will contain sample security keys and certificates. A WebPages2 subdirectory will contain sample web pages for use with the MPFS2 file system. An MPLAB.X project folder contains the MPLAB X project files for the demo. A Precompiled Hex subdirectory contains precompiled hex images of the demo project. Other stack-specific folders include are: The Microchip folder contains stack files and components. The Include sub-folder under the Microchip folder contains header files for Microchip stack and library solutions. The TCPIP Stack folder in the Include folder contains headers for the TCP/IP Stack. The TCPIP Stack folder in the Microchip folder contains C source files, documentation, and stack utilities. The Demo Board Files subdirectory contains information about the different demo boards ( run the TCP/IP stack. see page 64) that can
The Utilities subdirectory contains PC-based utilities that can help when using the stack. See the Software ( see page 59) section for more information. The source code for the Microchip TCP/IP Discoverer ( see page 62), the MPFS2 ( see page 59) tool, and the MPFS library is located in the Source subdirectory in the Utilities directory. In most cases, it will not be necessary to modify source or header files in the Microchip directory.
2 SW License Agreement
MICROCHIP IS WILLING TO LICENSE THE ACCOMPANYING SOFTWARE AND DOCUMENTATION TO YOU ONLY ON THE CONDITION THAT YOU ACCEPT ALL OF THE FOLLOWING TERMS. TO ACCEPT THE TERMS OF THIS LICENSE, CLICK "I ACCEPT" AND PROCEED WITH THE DOWNLOAD OR INSTALL. IF YOU DO NOT ACCEPT THESE LICENSE TERMS, CLICK "I DO NOT ACCEPT," AND DO NOT DOWNLOAD OR INSTALL THIS SOFTWARE.
This Nonexclusive Software License Agreement ("Agreement") is a contract between you, your heirs, successors and assigns ("Licensee") and Microchip Technology Incorporated, a Delaware corporation, with a principal place of business at 2355 W. Chandler Blvd., Chandler, AZ 85224-6199, and its subsidiary, Microchip Technology (Barbados) II Incorporated (collectively, "Microchip") for the accompanying Microchip software including, but not limited to, Graphics Library Software, IrDA Stack Software, MCHPFSUSB Stack Software, Memory Disk Drive File System Software, mTouch(TM) Capacitive Library Software, Smart Card Library Software, TCP/IP Stack Software, MiWi(TM) DE Software, and/or any PC programs and any updates thereto (collectively, the "Software"), and accompanying documentation, including images and any other graphic resources provided by Microchip ("Documentation").
1. Definitions. As used in this Agreement, the following capitalized terms will have the meanings defined below: a. "Microchip Products" means Microchip microcontrollers and Microchip digital signal controllers. b. "Licensee Products" means Licensee products that use or incorporate Microchip Products. c. "Object Code" means the Software computer programming code that is in binary form (including related documentation, if any), and error corrections, improvements, modifications, and updates. d. "Source Code" means the Software computer programming code that may be printed out or displayed in human readable form (including related programmer comments and documentation, if any), and error corrections, improvements, modifications, and updates. e. "Third Party" means Licensees agents, representatives, consultants, clients, customers, or contract manufacturers. f. "Third Party Products" means Third Party products that use or incorporate Microchip Products.
2. Software License Grant. Microchip grants strictly to Licensee a non-exclusive, non-transferable, worldwide license to: a. use the Software in connection with Licensee Products and/or Third Party Products; b. if Source Code is provided, modify the Software, provided that no Open Source Components (defined in Section 5 below) are incorporated into such Software in such a way that would affect Microchips right to distribute the Software with the limitations set forth herein and provided that Licensee clearly notifies Third Parties regarding such modifications; c. distribute the Software to Third Parties for use in Third Party Products, so long as such Third Party agrees to be bound by this Agreement (in writing or by "click to accept ( see page 166)") and this Agreement accompanies such distribution; d. sublicense to a Third Party to use the Software, so long as such Third Party agrees to be bound by this Agreement (in writing or by "click to accept ( see page 166)"); e. with respect to the TCP/IP Stack Software, Licensee may port the ENC28J60.c, ENC28J60.h, ENCX24J600.c, and ENCX24J600.h driver source files to a non-Microchip Product used in conjunction with a Microchip ethernet controller; f. with respect to the MiWi (TM) DE Software, Licensee may only exercise its rights when the Software is embedded on a Microchip Product and used with a Microchip radio frequency transceiver or UBEC UZ2400 radio frequency transceiver 3
Microchip TCP/IP Stack Help which are integrated into Licensee Products or Third Party Products. For purposes of clarity, Licensee may NOT embed the Software on a non-Microchip Product, except as described in this Section.
3. Documentation License Grant. Microchip grants strictly to Licensee a non-exclusive, non-transferable, worldwide license to use the Documentation in support of Licensee's authorized use of the Software
4. Third Party Requirements. Licensee acknowledges that it is Licensees responsibility to comply with any third party license terms or requirements applicable to the use of such third party software, specifications, systems, or tools. Microchip is not responsible and will not be held responsible in any manner for Licensees failure to comply with such applicable terms or requirements.
5. Open Source Components. Notwithstanding the license grant in Section 1 above, Licensee further acknowledges that certain components of the Software may be covered by so-called "open source" software licenses ("Open Source Components"). Open Source Components means any software licenses approved as open source licenses by the Open Source Initiative or any substantially similar licenses, including without limitation any license that, as a condition of distribution of the software licensed under such license, requires that the distributor make the software available in source code format. To the extent required by the licenses covering Open Source Components, the terms of such license will apply in lieu of the terms of this Agreement. To the extent the terms of the licenses applicable to Open Source Components prohibit any of the restrictions in this Agreement with respect to such Open Source Components, such restrictions will not apply to such Open Source Component.
6. Licensee Obligations. Licensee will not: (i) engage in unauthorized use, modification, disclosure or distribution of Software or Documentation, or its derivatives; (ii) use all or any portion of the Software, Documentation, or its derivatives except in conjunction with Microchip Products or Third Party Products; or (iii) reverse engineer (by disassembly, decompilation or otherwise) Software or any portion thereof. Licensee may not remove or alter any Microchip copyright or other proprietary rights notice posted in any portion of the Software or Documentation. Licensee will defend, indemnify and hold Microchip and its subsidiaries harmless from and against any and all claims, costs, damages, expenses (including reasonable attorney's fees), liabilities, and losses, including without limitation product liability claims, directly or indirectly arising from or related to the use, modification, disclosure or distribution of the Software, Documentation, or any intellectual property rights related thereto; (ii) the use, sale and distribution of Licensee Products or Third Party Products; and (iii) breach of this Agreement.
7. Confidentiality. Licensee agrees that the Software (including but not limited to the Source Code, Object Code and library files) and its derivatives, Documentation and underlying inventions, algorithms, know-how and ideas relating to the Software and the Documentation are proprietary information belonging to Microchip and its licensors ("Proprietary Information"). Except as expressly and unambiguously allowed herein, Licensee will hold in confidence and not use or disclose any Proprietary Information and will similarly bind its employees and Third Party(ies) in writing. Proprietary Information will not include information that: (i) is in or enters the public domain without breach of this Agreement and through no fault of the receiving party; (ii) the receiving party was legally in possession of prior to receiving it; (iii) the receiving party can demonstrate was developed by the receiving party independently and without use of or reference to the disclosing party's Proprietary Information; or (iv) the receiving party receives from a third party without restriction on disclosure. If Licensee is required to disclose Proprietary Information by law, court order, or government agency, License will give Microchip prompt notice of such requirement in order to allow Microchip to object or limit such disclosure. Licensee agrees that the provisions of this Agreement regarding unauthorized use and nondisclosure of the Software, Documentation and related Proprietary Rights are necessary to protect the legitimate business interests of Microchip and its licensors and that monetary damage alone cannot adequately compensate Microchip or its licensors if such provisions are violated. Licensee, therefore, agrees that if Microchip alleges that Licensee or Third Party has breached or violated such provision then Microchip will have the right to injunctive relief, without the requirement for the posting of a bond, in addition to all other remedies at law or in equity.
Microchip TCP/IP Stack Help 8. Ownership of Proprietary Rights. Microchip and its licensors retain all right, title and interest in and to the Software and Documentation including, but not limited to all patent, copyright, trade secret and other intellectual property rights in the Software, Documentation, and underlying technology and all copies and derivative works thereof (by whomever produced). Licensee and Third Party use of such modifications and derivatives is limited to the license rights described in Sections this Agreement.
9. Termination of Agreement. Without prejudice to any other rights, this Agreement terminates immediately, without notice by Microchip, upon a failure by Licensee or Third Party to comply with any provision of this Agreement. Upon termination, Licensee and Third Party will immediately stop using the Software, Documentation, and derivatives thereof, and immediately destroy all such copies.
10. Warranty Disclaimers. THE SOFTWARE AND DOCUMENTATION ARE PROVIDED "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESS OR IMPLIED, INCLUDING WITHOUT LIMITATION, ANY WARRANTY OF MERCHANTABILITY, TITLE, NON-INFRINGEMENT AND FITNESS FOR A PARTICULAR PURPOSE. MICROCHIP AND ITS LICENSORS ASSUME NO RESPONSIBILITY FOR THE ACCURACY, RELIABILITY OR APPLICATION OF THE SOFTWARE OR DOCUMENTATION. MICROCHIP AND ITS LICENSORS DO NOT WARRANT THAT THE SOFTWARE WILL MEET REQUIREMENTS OF LICENSEE OR THIRD PARTY, BE UNINTERRUPTED OR ERROR-FREE. MICROCHIP AND ITS LICENSORS HAVE NO OBLIGATION TO CORRECT ANY DEFECTS IN THE SOFTWARE.
11. Limited Liability. IN NO EVENT WILL MICROCHIP OR ITS LICENSORS BE LIABLE OR OBLIGATED UNDER ANY LEGAL OR EQUITABLE THEORY FOR ANY DIRECT OR INDIRECT DAMAGES OR EXPENSES INCLUDING BUT NOT LIMITED TO INCIDENTAL, SPECIAL, INDIRECT, PUNITIVE OR CONSEQUENTIAL DAMAGES, LOST PROFITS OR LOST DATA, COST OF PROCUREMENT OF SUBSTITUTE GOODS, TECHNOLOGY, SERVICES, OR ANY CLAIMS BY THIRD PARTIES (INCLUDING BUT NOT LIMITED TO ANY DEFENSE THEREOF), OR OTHER SIMILAR COSTS. The aggregate and cumulative liability of Microchip and its licensors for damages hereunder will in no event exceed $1000 or the amount Licensee paid Microchip for the Software and Documentation, whichever is greater. Licensee acknowledges that the foregoing limitations are reasonable and an essential part of this Agreement.
12. General. THIS AGREEMENT WILL BE GOVERNED BY AND CONSTRUED UNDER THE LAWS OF THE STATE OF ARIZONA AND THE UNITED STATES WITHOUT REGARD TO CONFLICTS OF LAWS PROVISIONS. Licensee agrees that any disputes arising out of or related to this Agreement, Software or Documentation will be brought in the courts of the State of Arizona. This Agreement will constitute the entire agreement between the parties with respect to the subject matter hereof. It will not be modified except by a written agreement signed by an authorized representative of the Microchip. If any provision of this Agreement will be held by a court of competent jurisdiction to be illegal, invalid or unenforceable, that provision will be limited or eliminated to the minimum extent necessary so that this Agreement will otherwise remain in full force and effect and enforceable. No waiver of any breach of any provision of this Agreement will constitute a waiver of any prior, concurrent or subsequent breach of the same or any other provisions hereof, and no waiver will be effective unless made in writing and signed by an authorized representative of the waiving party. Licensee agrees to comply with all export laws and restrictions and regulations of the Department of Commerce or other United States or foreign agency or authority. The indemnities, obligations of confidentiality, and limitations on liability described herein, and any right of action for breach of this Agreement prior to termination, will survive any termination of this Agreement. Any prohibited assignment will be null and void. Use, duplication or disclosure by the United States Government is subject to restrictions set forth in subparagraphs (a) through (d) of the Commercial Computer-Restricted Rights clause of FAR 52.227-19 when applicable, or in subparagraph (c)(1)(ii) of the Rights in Technical Data and Computer Software clause at DFARS 252.227-7013, and in similar clauses in the NASA FAR Supplement. Contractor/manufacturer is Microchip Technology Inc., 2355 W. Chandler Blvd., Chandler, AZ 85224-6199.
If Licensee has any questions about this Agreement, please write to Microchip Technology Inc., 2355 W. Chandler Blvd., Chandler, AZ 85224-6199 USA. ATTN: Marketing.
3 Release Notes
****** Microchip TCP/IP Stack Version Log: ****** Remarks Please file bug-reports/bug-fixes at http://support.microchip.com/ or post to the Microchip TCP/IP -> Ethernet Forum at http://forum.microchip.com/ Look for stack updates at http://www.microchip.com/mal/
****** v5.36.4 Oct 2011 ****** Changes: 1. SNMPNotify ( see page 323)() is updated to support ASCII string varible type for both TRAPv1 and TRAPv2.ASCII string address pointer is assigned to argument val(SNMP_VAL ( see page 320)) of SNMPNotify ( see page 323)(). 2. The SSL module has been updated to support 1024-bit RSA key lengths for server and client on all architectures. PIC32 microcontrollers now support client/server RSA key lengths of 2048 bits. NOTE: To support these changes, you must manually modify your copy of RSA.c. A description of the required changes ("Required SSL Changes.pdf") can be found in your Microchip Applications Libraries installation directory in the "MicrochipHelpSupplementary TCPIP Help" subdirectory. Fixes: 1. SNMP local variable community length increased with plus one.SNMP warnings has been removed for the compiler version C32 2.01 for zero optimisation. 2. Updated MPFS2.jar and mib2bib.jar to support Java version 1.7. 3. Fixed MPFS2.jar offset issue for fileRcrd.bin and dynRcrd.bin file and it was due to the file which has zero dynamic variable.Fixed Crimson editor problem with webPage2 folder where user couldn't save files using Crimson Editor if the WebPages2 folder that contained those files was selected in the MPFS2 utility. 4. MPFS2.jar file was getting hanged for the zero file size access.Now Zero file size also is the part of the respective generated files. Known Problems: 1. Telnet ( see page 485) server module does not implement a lot of Telnet ( see page 485) functions. As a result, it will likely not display correctly or work at all with some Telnet ( see page 485) clients. The server was tested with the Microsoft telnet.exe utility which is provided with Microsoft Windows. 2. If the DHCP client and DHCP server are used at the same time and you connect ( see page 168) two similar boards to each other (ex: two PICDEM.net 2 boards connected via a crossover cable), a race condition can occur where both nodes will disable their DHCP server and neither board will get a successful DHCP lease. If this unlikely scenario occurs, as a work around, simply reset one of the boards to reenable it's DHCP server. 3. LCDBlocking.c timing for the LCD_E_IO enable signal is too fast to meet published data sheet limits for various LCD controllers when compiling for a PIC32 running at > 43MHz. Despite this potential timing violation, the LCD does normally work correctly on the precompiled PIC32 demos for the Explorer 16 at 80MHz. 4. For PIC32 implementations, depending on the configuration, it is possible that the MACGetFreeRxSize() returns a value greater than 64 KB. For backward compatibility reasons the stack uses a 16 bit value to check the returned value and it won't work corretly. 5. Limiting the number of UDP sockets to 8 in the stack demos may prevent SNMP trap functionality. If this occurs, you can increase the MAX_UDP_SOCKETS definition in TCPIPConfig.h to 10 (if your system will support the increased data memory usage) to fix this issue. 7
Microchip TCP/IP Stack Help 6. The SNMP mib file's date and version parameter does not match the date/version of the current stack release.
****** v5.36.2 July 2011 ****** Changes: 1. Removed the Google PowerMeter and Google PowerMeter EZConfig demos. Google, Inc. has deprecated Google PowerMeter and has expressed the intent to remove access to it on September 16, 2011. To obtain Microchip Technology's Google PowerMeter reference implementation, you can download the June 2011 Microchip Application Libraries archived release from www.microchip.com/mal. 2. Modified the Energy Monitoring demo to remove Google PowerMeter functionality. The demo will still display measured power data on its internal web page. 3. Updated the TCP/IP Stack Performance table to use the testing methodology from previous releases. More information is available in the TCP/IP Stack Help file. 4. gSnmpNonMibRecInfo ( see page 114)[] has been moved from snmp.c file to CustomSNMPApp.c file and SNMP_MAX_NON_REC_ID_OID ( see page 115) macro has been moved from snmp.h file to CustomSNMPApp.c file. gSnmpNonMibRecInfo ( see page 114)[] is used to list the static variables parent OID strings which are not part of mib.h file. This structure is used to restrict the access to the SNMPv3 objects from SNMPv2c and SNMPv1 version requests. Macro STACK_USE_SMIV2 ( see page 115) is used to support gSnmpNonMibRecInfo ( see page 114)[] with MODULE-IDENTITY number. For V5.31 STACK_USE_SMIV2 ( see page 115) need to commented. 5. Removed the SPI2CON register freeze-on-halt bit macro from the SPIFlash, RAM, and EEPROM driver files to provide compatibility with C32 v2.00. Fixes: 1. Removed the MPFSImg2 files from the MPLAB X C18/C30 projects so that the projects will compile. Disabled MPFSImg2.c for PIC32 Explorer 16 projects. 2. Added a heap and minimum stack size for the PIC32 Ethernet Starter Kit MPLAB X project. 3. The TCP/IP Stack Help File's performance table has been updated using the same test procedure used in previous releases. Known Problems: 1. Telnet ( see page 485) server module does not implement a lot of Telnet ( see page 485) functions. As a result, it will likely not display correctly or work at all with some Telnet ( see page 485) clients. The server was tested with the Microsoft telnet.exe utility which is provided with Microsoft Windows. 2. If the DHCP client and DHCP server are used at the same time and you connect ( see page 168) two similar boards to each other (ex: two PICDEM.net 2 boards connected via a crossover cable), a race condition can occur where both nodes will disable their DHCP server and neither board will get a successful DHCP lease. If this unlikely scenario occurs, as a work around, simply reset one of the boards to reenable it's DHCP server. 3. LCDBlocking.c timing for the LCD_E_IO enable signal is too fast to meet published data sheet limits for various LCD controllers when compiling for a PIC32 running at > 43MHz. Despite this potential timing violation, the LCD does normally work correctly on the precompiled PIC32 demos for the Explorer 16 at 80MHz. 4. For PIC32 implementations, depending on the configuration, it is possible that the MACGetFreeRxSize() returns a value greater than 64 KB. For backward compatibility reasons the stack uses a 16 bit value to check the returned value and it won't work corretly. 5. Limiting the number of UDP sockets to 8 in the stack demos may prevent SNMP trap functionality. If this occurs, you can increase the MAX_UDP_SOCKETS definition in TCPIPConfig.h to 10 (if your system will support the increased data memory usage) to fix this issue. 6. The SNMP mib file's date and version parameter does not match the date/version of the current stack release.
****** Changes: 1. Because of changes to the SHOUTcast server configuration, the Internet Radio demo is no longer functional. This demo has been retained in the stack distribution to provide a TCP/IP code example. 2. The UDP module will now perform address resolution and DNS querying automatically. As a result, the UDP module APIs have changed. The UDPOpenEx ( see page 523) function provides this additional functionality. Please consult the TCP/IP Stack Help File's "Stack API > UDP" topic for more information. 3. The UDPOpen ( see page 524) macro has been added to conform to the legacy UDPOpen ( see page 524) interface.
4. The Announce ( see page 152), BerkeleyAPI, DHCP client/server, DNS client/server, NBNS, Reboot ( see page 314), SNMP, SNTP, TFTPc, UDPPerformanceTest, and ZeroConf modules have been updated to use the new UDP API. The iPerf demo has also been updated. 5. The MPFS Classic and HTTP(1) modules have been removed from the stack. Function- ality to support these modules has also been removed from the TCP/IP Stack software tools. MPFS2 and HTTP2 are still supported. 6. The UARTConfig demo module has been updated to upload MPFS2 images to the demo board in place of MPFS Classic images. 7. To facilitate linking on PIC18 platforms, the number of UDP sockets in demo projects has been reduced from 10 to 8. 8. The SNMP Stack application and mib2bib.jar PC utility now both support 1024 dynamic IDs. 9. SNMP_DEMO_TRAP is a new dynamic variable added to the snmp.mib file to support SMIv2 with TRAPv2. This will correct a previously existing issue viewing traps with the iReasoning MIB browser. As per those changes, the mchp.mib file has been modified to support the SMIv2 standard. This mib includes MODULE-IDENTITY which will provide MICROCHIP and MIB information. snmp.mib also includes MODULE-IDENTIY(1), a new number (1) to the existing OID after ENTERPRISE-ID(17095). 10. Added a preprocessor check that will include the ultoa function if a version of the C32 compiler earlier than 1.12 is used. 11. Modified the WiFi module to use separate retry counters for AdHoc and Infrastructure modes. 12. Modified Berkeley API module to accept ( see page 166) IPPROTO_IP ( see page 171) as a valid protocol for the socket function. The code will determine the protocol type from the socket type (datagram or stream). 13. Created MPLAB X projects corresponding to most MPLAB 8 projects and configurations. These projects are located in the MPLAB.X subfolder in the associated demo project directory. The MPLAB X import wizard can be used to create MPLAB X projects from MPLAB 8 projects that don't have an analogue in the new demo project folders. 14. Added project support for the dsPIC33E and PIC24E architectures. 15. All TCP/IP Stack demo projects have been moved to the "TCPIP" subdirectory in the stack installation directory. 16. Created Java versions of several TCP/IP tools to provide cross-platform support. The TCP/IP Configuration Wizard has not been ported to Java; thus, it is only available for Windows users. 17. To prevent issues with path length, MPLAB 8 project names have been changed. A list of the abbreviations used in the project names is available in the MAL help folder (Microchip Solutions/Microchip/Help/Abbreviations.htm). The names of the HardwareProfile and TCPIPConfig configuration files have been abbreviated as well. 18. Changed the configuration inclusion macros used by the TCP/IP Stack demo projects to match the terms used in the project/configuration names. 19. The "Alternative Configurations" subfolders in most demo projects has been renamed to "Configs." 20. Added a Google PowerMeter demo for use with the PIC18F87J72 Energy Monitoring PICtail. 21. The Web Preview tool is no longer included with the stack. Fixes: 1. Fixed a DHCP Server (DHCPs.c) lease leak problem that would occur when STACK_USE_ZEROCONF_LINK_LOCAL was defined. This problem would have resulted in the DHCP server stop giving out any leases until being rebooted. 2. Updated the PIC32MX6XX/7XX external PHY SMSC 8720LAN reference design. 3. Fixed bug with window expecting MACGetFreeRxSize() to return values < 32KB. 4. Fixed a type casting bug with the CalcIPChecksum ( see page 213) function that would cause an incorrect TX checksum if the checksum value overflowed again after adding the carry bits to the checksum value.
Microchip TCP/IP Stack Help 5. Fixed a bug in the AutoIP module that may have prevented the module from correctly defending its own address. 6. Added a check to the Announce ( see page 152) module to ensure the MAC layer is linked before attemping to transmit an Announce ( see page 152) message. 7. Fixed a bug in the ETH97J60 MACPut function. 8. Added an additional preprocessor check in a debug menu setting in WF_Spi.c to prevent a build error. 9. Added a fix to the Google PowerMeter demo code to restore SNTP timestamp sourcing if SNTP is enabled. Previously, it would be overwritten by a possibly invalid HTTP timestamp. Known Problems: 1. Telnet ( see page 485) server module does not implement a lot of Telnet ( see page 485) functions. As a result, it will likely not display correctly or work at all with some Telnet ( see page 485) clients. The server was tested with the Microsoft telnet.exe utility which is provided with Microsoft Windows. 2. If the DHCP client and DHCP server are used at the same time and you connect ( see page 168) two similar boards to each other (ex: two PICDEM.net 2 boards connected via a crossover cable), a race condition can occur where both nodes will disable their DHCP server and neither board will get a successful DHCP lease. If this unlikely scenario occurs, as a work around, simply reset one of the boards to reenable it's DHCP server. 3. LCDBlocking.c timing for the LCD_E_IO enable signal is too fast to meet published data sheet limits for various LCD controllers when compiling for a PIC32 running at > 43MHz. Despite this potential timing violation, the LCD does normally work correctly on the precompiled PIC32 demos for the Explorer 16 at 80MHz. 4. For PIC32 implementations, depending on the configuration, it is possible that the MACGetFreeRxSize() returns a value greater than 64 KB. For backward compatibility reasons the stack uses a 16 bit value to check the returned value and it won't work corretly. 5. Limiting the number of UDP sockets to 8 in the stack demos may prevent SNMP trap functionality. If this occurs, you can increase the MAX_UDP_SOCKETS definition in TCPIPConfig.h to 10 (if your system will support the increased data memory usage) to fix this issue. 6. The SNMP mib file's date and version parameter does not match the date/version of the current stack release.
****** v5.31 19 October 2010 ****** Changes: 1. Reorganized demo projects. The TCPIP ENCX24J600 Demo App, TCPIP PIC32 ETH Demo App, and TCPIP WiFi Demo App projects in stack versions 5.25 and prior have all been merged into the TCPIP Demo App folder. All four of these projects were almost identical to each other, with the primary difference being the network interface controller the projects were preconfigured to support. In this 5.31 TCP/IP Stack release, each hardware combination now has its own MPLAB IDE project in the TCPIP Demo App folder. 2. Reorganized HardwareProfile.h and TCPIPConfig.h structure for the TCPIP Demo App, TCPIP Google PowerMeter Demo App, and TCPIP WebVend App projects. Now, instead of having one massive HardwareProfile.h file that supports a multitude of hardware platforms simultaneously, simple individual hardware profiles have been created for specific hardware combinations and placed in the "Alternative Configurations" sub-folder. The correct hardware profile or TCPIP config file is selected by #including "HardwareProfile.h" or "TCPIPConfig.h" as in previous stack versions. However, the active hardware profile or config file from the Alternative Configurations folder is selected by a preprocessor macro defined in the MPLAB project settings (passed on the command line to the compiler). 3. Added HTTP_SAVE_CONTEXT_IN_PIC_RAM option to TCPIPConfig.h (HTTP2 server module). This option, when enabled, will increase HTTP2 server performance when servicing multiple simultaneous connections at the expense of using more PIC RAM. 4. Added automatic TPIN+/- polarity swapping logic to ETH97J60.c driver for PIC18F97J60 family devices. Some 3rd party Ethernet switches, routers, and end devices have their TX+/- pins wired backwards such that the remote TX+ signal connects to the PIC TPIN- pin and the remote TX- signal connects to the PIC TPIN+ pin. Because 10BaseT Ethernet signaling is polarized and the PIC18F97J60 family does not implement an auto-polarity feature, this normally prevents all RX communications with these non-IEEE 802.3 compliant link partners. To work around this incompatibility, it is possible to implement circuitry to swap the RX+ and RX- signals before reaching the TPIN+ and TPIN- pins. The PICDEM.net 2 Rev 6 reference design includes this necessary circuitry (U6, U7, R54, and RX_SWAP GPIO output pin from PIC). This 10
Microchip TCP/IP Stack Help stack version automatically controls the RX_SWAP signal based on the ETH_RX_POLARITY_SWAP_TRIS and ETH_RX_POLARITY_SWAP_IO definitions in HardwareProfile.h. If these macros are undefined, then the automatic polarity swapping feature is disabled in the ETH97J60.c driver. 5. Added portable LFSRRand ( see page 225)() and LFSRSeedRand ( see page 226)() public functions to Helpers.c and removed all references to C rand() and srand() functions. The C rand() function returns a 15 bit integer on 8 and 16 bit PICs, but a 31 bit integer on PIC32s. The LFSRRand ( see page 225)() function returns a 16-bit integer, regardless of which PIC you are using. 6. Added support for various SST/Microchip brand SST25xxxxx SPI Flash chips to SPIFlash.c driver. Previously only devices supporting the Auto Address ( see page 144) Increment (AAI) Word Program opcode (0xAD) would work. Now, devices such as the SST2525VF010A should work, which require the AAI Byte program opcode (0xAF) instead. 7. Removed support for Spansion brand SPI Flash chips in the SPIFlash.c driver. If your application is already using one of these devices, continue to use the SPIFlash.c/.h files from TCP/IP Stack 5.25. These older files are API compatible with the current version, so can be dropped in by simply overwriting the SPIFlash.c and SPIFlash.h files. 8. Removed a -4 offset from the advirtised TCP Maximum Segment Size option (MSS) and TCP_MAX_SEG_SIZE_RX ( see page 480) configuration value in TCP.c. The default TCP MSS advertised is now 536 instead of 532. 9. For Wi-Fi projects in the TCPIP Demo App folder, changed MY_DEFAULT_LIST_RETRY_COUNT to WF_RETRY_FOREVER instead of 3. This changes default connection behavior to keep trying to connect ( 168) instead of just trying 3 times which makes more sense for demonstration. 10. Changed WF_Connect() beacon timeout to 40. 11. IFConfig command in TCPIP WiFi Console Demo App modified to return application-perspective MAC address from the AppConfig structure, and not the Wi-Fi serialized MAC address (they may not match if user desired custom MAC). 12. Updated the TCP/IP Configuration Wizard. The user can now configure wireless settings and stack settings seperately. Because of the changes to the TCPIPConfig.h file, the user must now select the specific copy of TCPIPConfig.h (or any of its variants) instead of selecting a project directory. Added the ability to select WF_RETRY_FOREVER in the Wi-Fi configuration settings. Added a selection parameter for BSD socket count. Added validation to check for the proper number of Berkeley sockets and TCP performance test sockets in the socket configuration screen (Advanced Settings) if either of these features are enabled. Added the ability to create sockets of the same type with different TX/RX buffer sizes in the socket configuration screen. 13. Updated the TCPIP WebVend Demo App to support Wi-Fi in several configurations. 14. Modified the Google PowerMeter demo to automatically determine the date/time from the HTTP module if the date/time cannot be obtained from the SNTP module. 15. Added a new Google Map project example to the Combo Demos folder. This example runs on a PIC24FJ256DA210 Development Board + Fast 100Mbps Ethernet PICtail Plus (or Ethernet PICtail Plus) + Truly 3.2" 240x320 display, TFT_G240320LTSW_118W_E (or Powertip 4.3" 480x272 display, PH480272T_005_I11Q). It also can run on the PIC32 Multimedia Expansion Board + PIC32 Ethernet Starter Kit. This demo connects to the Internet, sends an HTTP query for a specific map tile to the Google Static Maps API, and then displays the compressed tile to the graphics display. For more information, see the "Getting Started - Running the Graphics Google Map Demo.htm" file in the Combo DemosGoogle Map folder. 16. Added preliminary SNMPv3 module. This module, enabled with the STACK_USE_SNMPV3_SERVER option in TCPIPConfig.h, implements the Simple Network Management Protocol, version 3. Among other things, SNMPv3 adds secure authentication and cryptographic privacy as compared to SNMPv2C. This implementation currently only supports AES encryption (no DES support). It also has only been tested with the PIC32 Ethernet Starter Kit (TCPIP Demo App C32 - PIC32_ENET_SK_DM320004_INTERNAL_ETHERNET.mcp MPLAB IDE project). SNMPv3 on PIC18, PIC24, and dsPIC platforms are not supported at this time. Because AES encryption has specialized United States export requirements, this TCP/IP Stack release does not include the required AES library to enable SNMPv3. To obtain the needed AES library, you must purchase SW300052 v2.6 or later. Older v2.5 and previous versions include AES related files on them, but do not include the new AES files required by SNMPv3. For more information on using SNMP, refer to the TCP/IP Stack Help (Demo Information -> Available Demos -> TCPIP Demo App -> Demo Modules -> Network Management (SNMP) Server). 17. Altered the SaveAppConfig() function in MainDemo.c to store a more robust signature to EEPROM/SPI Flash when saving the AppConfig structure. In v5.25 and prior stack versions, when EEPROM or SPI Flash memory was available, the stack would automatically write a one byte marker character to address 0x000000 in the EEPROM/Flash indicating if a valid AppConfig structure was stored in the non-volatile memory. This resulted in the EEPROM/Flash contents being organized like the following: Address ( see page 144) Data Contents =================== ============================================== 0x000000: Marker Byte 0x000001: AppConfig structure MPFS_RESERVE_BLOCK: Start of MPFS/MPFS2 image containing web pages In this stack version, EEPOM/Flash contents will now contain: Address ( see page 144) Data Contents =================== ============================================== 0x000000: Length of AppConfig structure (16-bit integer) 11 see page
Microchip TCP/IP Stack Help 0x000002: IP checksum of the AppConfig default values, as defined in TCPIPConfig.h and WF_Config.h (16-bit integer). 0x000004: IP checksum of the subsequent EEPROM/Flash bytes of the AppConfig values. 0x000006: AppConfig structure MPFS_RESERVE_BLOCK: Start of MPFS/MPFS2 image containing web pages The additional checkums allow automatic detection to occur if you change one of the values in TCPIPConfig.h or WF_Config.h that affects AppConfig. If you change one of the values in code, then upon boot up, the application will automatically detect this change and start using the values that you selected in code. If, at run time, you decide to change the AppConfig values and commit the changes to EEPROM/Flash, then the stack will subsequently use the run-time saved values on future reboots. The checksum at offset 0x000004 ensures that if any corrupted AppConfig contents are found in EEPROM/Flash (ex: power is lost between writing the signature structure and actual AppConfig structure, or code unintentionally overwrites something in the AppConfig memory area), then the original defaults defined in TCPIPConfig.h and WF_Config.h will be used instead of the corrupted values. This EEPROM/SPI Flash change affects all projects except TCPIP Internet Radio App, TCPIP Internet Bootloader App, and all PIC32 Starter Kit projects since these projects do not have or use external EEPROM or SPI Flash memory. Fixes: 1. Fixed a UDP bug in which a transmitted packet would have been addressed to the wrong destination node if the UDP socket received a broadcast packet from a different remote node from the last received packet, but using the same source port number as the last received packet. The FindMatchingSocket ( see page 473)() function in UDP.c will now always change the local socket parameters to send to the most recent remote node's unicast IP address, regardless of if the last received packet was addressed to a multicast or broadcast destination. Thanks go to Billy Walton for reporting this erroneous behavior. If you wish to change the destination IP/MAC addresses or port number for a UDP packet that you are ready to send, write the new parameters to the UDPSocketInfo ( see page 539)[SocketHandle] global structure before calling UDPFlush ( see page 526)(). This structure contains remoteNode and remotePort parameters for the remote IP address/MAC address and remote UDP port, respectively. You can also read these values to obtain the remote addressing parameters for the last received packet on the given UDP socket. Note that "SocketHandle" refers to the UDP socket handle returned by the UDPOpen ( see page 524)() API, not the literal string "SocketHandle". 2. Fixed ADC state save/restore bug in GenerateRandomDWORD ( see page 217)() function in Helpers.c. PIC24, dsPIC, and PIC32 platforms require the ADC ON/ADON bit to be cleared before modifying certain other ADC register contents. 3. Fixed an ENC28J60 MAC/MII register write timing violation when using a PIC24H or dsPIC at over 33MIPS. There was inadequate Chip Select hold time provided, violating the 210ns minimum specified in the ENC28J60 data sheet. This violation may have resulted in certain devices losing the ability to receive packets (due to the MARXEN bit, MACON1<0>, getting cleared unintentionally). 4. Fixed an ENCX24J600.c driver bug in which operating at 100Mbps with the ENC424J600/624J600 Ethernet controller, it would be possible for the MACGetHeader() function to issue a Reset() operation under rare circumstances. The PIC would reset whenever the PHY detected an illegal symbol during 4B5B decoding but guessed the correct 4B symbol such that no data corruption or CRC error occurred. This condition results in a valid packet being received but with the Received Ok Receive Status Vector bit being clear (RSV<23> == 0). This issue would become more probable when using very long Ethernet cables (ex: 100 meters) and receiving a lot of data. 5. Fixed a TCP bug in which calling TCPDisconnect ( see page 446)() to close a connection when the remote node's RX window was 0 bytes would have caused the stack to enter an infinite loop sending duplicate ACK packets. 6. Fixed Wi-Fi bug that caused assert condition if too many management messages were being received during data traffic. 7. Fixed Wi-Fi bug that caused WF_EVENT_CONNECTION_RESTABLISHED event case to send the wrong notification to the app. 8. Fixed Wi-Fi bug that caused assert failure with Scratch move failure. 9. Fixed Wi-Fi bug in WF_CAGetChannelList ( see page 561)() and WF_CAGetSecurity that caused failure.
10. Fixed Wi-Fi EasyConfig bug that required development boards to be manually reset even after new network was selected. 11. Fixed MRF24WB0 bug that caused assert if invalid WPA/WPA2 key was entered. 12. Fixed Wi-Fi power management bit behavior in PS-Poll frame that was causing some APs to never send data or disconnect when in power save mode. 13. Fixed a TCP bug in which attempting to open a client TCP socket to a remote server, specified by IP address (not DNS address), that was offline, but who's MAC address was already cached by the ARP client, would result in endless back-offs. For example, when attempting to contact the remote node (that was not responding), the TCP module would have transmitted a SYN at time T=0 seconds, T=1s, T=3s, T=7s, T=15s, T=31s, T=63s, T=127s, T=255s, etc. The exponential back-off between retransmissions would grow indefinitely until the retransmission interval would have grown so large that effectively no-retransmissions would be occurring. Assuming the application wasn't written with its own 12
Microchip TCP/IP Stack Help timeout to prevent endless waiting, this would prevent the socket from automatically establishing the connection to the remote server once the server came back online. With this TCP fix, the exponential back off now saturates after TCP_MAX_RETRIES ( see page 480) (5) back offs and continues to retransmit using the same interval. By default, this means SYN transmissions will occur at T=0 seconds, T=1s, T=3s, T=7s, T=15s, T=31s, T=63s, T=95s, T=127s, etc. After 5 back-offs the retransmission interval stops growing and stays constant at 32 seconds. 14. Fixed an RSA computation bug that would cause the RSA module to never complete if you attempted to compute y = x^e % n where e = 3 (or similar number < 256 with only 0, 1, or 2 bits set). Thanks go to Kevin Maidment for pointing this error out and suggesting a solution. Note, that this fix to RSA.c is not distributed with the ordinary TCP/IP Stack due to United States export restrictions. To get this fix, you must repurchase SW300052. This fix is included in SW300052 v2.6 or later. If you don't have CD media to identify the SW300052 version that you have, you can test the RSA.c file that you have. RSA.c in SW300052 v2.6 has a CRC32 checksum of 0x91F66711. RSA.c in v2.5 and prior had a checksum of 0xB1E8B0CC. Known Problems: 1. Telnet ( see page 485) server module does not implement a lot of Telnet ( see page 485) functions. As a result, it will likely not display correctly or work at all with some Telnet ( see page 485) clients. The server was tested with the Microsoft telnet.exe utility which is provided with Microsoft Windows. 2. If the DHCP client and DHCP server are used at the same time and you connect ( see page 168) two similar boards to each other (ex: two PICDEM.net 2 boards connected via a crossover cable), a race condition can occur where both nodes will disable their DHCP server and neither board will get a successful DHCP lease. If this unlikely scenario occurs, as a work around, simply reset one of the boards to reenable it's DHCP server. 3. LCDBlocking.c timing for the LCD_E_IO enable signal is too fast to meet published data sheet limits for various LCD controllers when compiling for a PIC32 running at > 43MHz. Despite this potential timing violation, the LCD does normally work correctly on the precompiled PIC32 demos for the Explorer 16 at 80MHz.
****** v5.25 07 May 2010 ****** Changes: 1. Added support for the Microchip MRF24WB0 802.11 WiFi controller (module part number MRF24WB0MA). This product is intended as a backwards compatible, drop in replacement to the ZG2100. The MRF24WB0MA should work with previous TCP/IP Stack versions as if it were a ZG2100M, but when the MRF24WB0MA is used with this (5.25) and future TCP/IP Stack versions, feature improvements inside the MRF24WB0 allow the TCP/IP Stack code/RAM size to be smaller and run faster. 2. Dropped support for the ZeroG ZG2100 802.11 WiFi controller. Applications that must stay with this device should continue to use TCP/IP Stack version 5.20b or earlier. All new projects or preexisting projects undergoing updates should be developed with the MRF24WB0 instead. 3. The WiFi connection management state machines now run on the MRF24WB0 instead of the PIC host, freeing up code and data space. Connection profiles can be created and the connection algorithm fine-tuned by the PIC application. In the WiFi demos see the WF_Connect function in MainDemo.c for an example of how to configure and then establish a WiFi connection. The programming model has changed to an API model which is documented in 'TCPIP Stack Help.chm'. 4. Changed "VERSION" macro definition in TCPIP.h to "TCPIP_STACK_VERSION". "VERSION" is overly generic and will likely conflict with other identical tokens one may use in their application code or source libraries. 5. Added support for the PIC24FJ256GA110, PIC24FJ256GB110 and PIC24FJ256GB210 PIMs for the Explorer 16. Note that when using the PIC24FJ256GA110 general purpose PIM, the Ethernet PICtail Plus, Fast 100Mbps Ethernet PICtail Plus, MRF24WB0MA Wi-Fi PICtail Plus, or other SPI PICtail daughter board should be installed in the middle SPI2 slot of the Explorer 16, not the ordinary topmost SPI1 slot used by other PIMs, including the PIC24FJ256GB110 and PIC24FJ256GB210 ones. The software is set up to use SPI2 for the PIC24FJ256GA110 PIM to avoid incompatibilities with silicon revision A3, which does not allow the SCK1 pin to be configured as a PPS output. 6. Added support for the PIC24FJ256DA210 Development Board. 7. Added TFTPUploadRAMFileToHost ( see page 502)(), TFTPUploadFragmentedRAMFileToHost ( see page 501)() and TFTPGetUploadStatus ( see page 500)() APIs to the TFTPc.c file. These APIs provide a very simple means of uploading a whole file to a remote TFTP server without requiring a great deal of application state machine logic. These 13
Microchip TCP/IP Stack Help APIs require the DNS client module to be enabled (STACK_USE_DNS must be defined, in addition to STACK_USE_TFTP_CLIENT). 8. Added a dummy DNS Server module. This server always sends the local IP address in response to all queries received. When using the PIC DHCP server, its purpose is to allow a user to type anything into a web browser (ex: http://asdf/) and still receive the web page provided by the PIC, much as a hotel or airport WiFi router will serve to you before you've paid or agreed to the network's terms of service. This DNS server module is implemented in DNSs.c, requires one UDP socket, and is enabled via the STACK_USE_DNS_SERVER option in TCPIPConfig.h. 9. Changed SPIFlash.h file defaults to target an SST SPI Flash with 4096 byte sectors instead of a Spansion Flash with 65536 byte sectors. These new defaults are, among other reasons, in support of the PIC24FJ256DA210 Development Board, which has an SST SST25VF016B on it. 10. Made TCP Keep-Alive packets consistently get sent TCP_KEEP_ALIVE_TIMEOUT ( see page 480) (default 10 seconds) after the last socket TX or RX activity. In earlier stack versions, if the local node transmitted some data and then let the socket go idle, the first Keep-Alive packet sent would use the TCP_START_TIMEOUT_VAL ( see page 483) (default 1 second) timer value before getting sent. While benign in terms of application behavior, these faster than normal keep-alive transmissions were distracting when viewed in Wireshark or other packet capture tools. 11. Disabled STACK_USE_DYNAMICDNS_CLIENT option in TCPIPConfig.h by default for the TCPIP Demo App and TCPIP ENCX24J600 Demo App projects. This option was enabled by default in earlier stack releases. This was done to save code size and allow out-of-box compilation on devices with 128KB of Flash when not using compiler optimizations. The TCPIP PIC32 ETH Demo App project continutes to have this option enabled by default. 12. Added SNMP v2 TRAP PDU format. Macro SNMP_STACK_USE_V2_TRAP is used to enable the SNMP v2 trap format. New API function SNMPV2TrapDemo() is included to support more than one variable binding to the SNMPv2 TRAP. This API can be used for a single SNMPv2 TRAP variable varbind and is part of CustomSNMPApp.c. A multiple variable binding demo can be enabled MainDemo.c. One should not enable both SNMPTrapDemo and SNMPV2TrapDemo simultaneously. Global flag "gSetTrapSendFlag ( see page 321)" is used to indicate the start and end of SNMPv2 trap varbinds. If gSetTrapSendFlag ( see page 321) is FALSE, then very next variable varbind for the SNMPv2 TRAP, is the last or only one variable varbind. If gSetTrapSendFlag ( see page 321) is TRUE, then there is another variable varbind available to be part of the SNMPv2 TRAP PDU. 13. Added support for PIC32MX6XX/7XX external PHY's: SMSC 8700LAN and National DP83640. 14. Added schematics and BOM for the PIC32 Ethernet Starter Kit. 15. Added the Google PowerMeter demo project. Consult the "Reference Implementation for Google PowerMeter.chm" help file for more information. 16. Modified the SSL and TCP modules to create the TCPStartSSLClientEx ( see page 469) function. This function will enable the SSL module to store supplementary data (currently only SSL Certificate Public Keys) in a structure. 17. Moved the HTTP_PORT ( see page 251), HTTPS_PORT ( see page 258), HTTP_MAX_DATA_LEN ( 251), and HTTP_MIN_CALLBACK_FREE ( see page 251) macros from HTTP2.c to TCPIPConfig.h. Fixes: 1. The SPIFlashEraseSector() function in the SPIFlash.c file incorrectly erased the sector specified by the current write pointer (set by calling SPIFlashBeginWrite()) instead of the specified dwAddr parameter address. This error had no impact on any TCP/IP Stack code as these parameters always matched. However, application code using the API would have been affected. Thanks go to Marc Boon for reporting this issue on the Microchip Ethernet forum. 2. Fixed ENC424J600/624J600 driver for PSP modes 2, 4, 6, and 10. The PIC's PMP PMMODE<9:8> bits were not set correctly. 3. Removed from lingering references to TickGetDiff() in FTP.c, TFTPc.c and UARTConfig.c. 4. Fixed DNS client module from returning the DNS server IP address if the DNS query failed due to a server error (i.e. DNS did respond, but did not return any records, such as when attempting to resolve a name that isn't in the DNS). DNSIsResolved ( see page 184)() will now return 0.0.0.0 on any non-recoverable DNS error or timeout. 5. Fixed HTTP2 MPFS upload page being accessible from URLs that weren't an exact match. For example, in 5.20 and earlier, accessing http://mchpboard/mpfsuploadASDF would still have opened the mpfsupload page. Thanks go to Andrea Rivolta on the Microchip Ethernet Forum for identifying this error. 6. Improved UDP TX checksum code for the special case when the computed checksum was 0x0000. According to the UDP RFC, for this corner case, the checksum should be converted to 0xFFFF before transmission to differentiate from the checksum disabled case, improving error detection by a minuscule amount. 7. Fixed GetCLKOUT() function in ENCX24J600.c driver file. Previously, 0x00 would always be returned, regardless of the value in the COCON bits of ECON2. The function documentation for SetCLKOUT() and GetCLKOUT() was also corrected (had obsolete information ported over from ENC28J60 driver file). 14 see page
Microchip TCP/IP Stack Help 8. Fixed DHCP client rebinding bug in which the DHCP client would request the wrong IP address if an unrelated DHCP OFFER or ACK message were received after we transmitted a DHCP REQUEST but before we received our DHCP ACK. Under rare conditions, this would have resulted in the TCP/IP stack reverting to the static or AutoIP assigned address for a few seconds between DHCP lease renewals. 9. Fixed TFTP Internet Bootloader bug in which uncommon .hex files containing a certain data pattern could not be uploaded correctly to the PIC18F97J60 family device. For these problem .hex files, a block of 32 program words (64 bytes) would remain unprogrammed (left as 0xFFFF) due to a parsing error in the bootloader's DecodeHex() function. The TFTP upload operation would succeed without reporting a programming error. The problem can be detected by using an ICD3 or similar ICSP programmer and reading the program Flash out of a device that is programmed with the bootloader and application .hex files. Compare the resulting memory dump to a device programmed only with the application .hex file. If you have devices deployed in the field with the previous bootloader and happen to generate a problem application .hex file, you can potentially work around the bootloader bug by opening the application .hex file with Notepad and appending dummy address records to the beginning to move the data around in the file. For example, at the very top of the .hex file, add lines containing ":020000040000FA" until the bootload process works correctly. You may alternatively try adding spaces at the end of any line, although this may make the .hex file incompatible with some programming utilities. Thanks go to Jonathan Seidmann for identifying and reporting this bug. 10. Fixed SNMPv2 TRAP format issue where SNMP browser was displaying all the SNMPv2 traps as SNMP version 1. SNMP v2 TRAP pdu format is rectified. Macro SNMP_STACK_USE_V2_TRAP is used to form and send a SNMPv2 TRAP PDU. SNMPTrapDemo API is used for both SNMPv1 and SNMPv2 single variable varbind trap. 11. Fixed an HTTP2.c server module initialization bug when using the PIC32MX7XX/6XX series internal Ethernet module. During initialization the HTTPLoadConn ( see page 256)() function would overwrite over 100 bytes of PIC RAM past the end of the reserved memory allocated for the HTTP2 module. This problem would manifest itself by locking up the TCPIP PIC32 ETH Demo App-C32 demo shortly after power up if you compiled TCP/IP Stack version 5.20 with the MPLAB C Compiler for PIC32 MCUs (C32) version 1.11. 12. Fixed SSL client from incorrectly parsing for the server's public key in rare cases where the RSA Public Key Algorithm identifier was received, but the key hadn't been received by TCP yet. Thanks go to Kevin Maimdnet for identifing this error in SSL.c and reporting it via http://support.microchip.com/. 13. Fixed Tick.c TickGet ( see page 516)(), TickGetDiv256 ( see page 516)() and TickGetDiv64K ( see page 517)() APIs sometimes returning the wrong value on PIC32 platforms. On the PIC32MX3XX/4XX family devices a wrong return result would sometimes occur if using -O3 compiler optimizations (maximum speed) with the Microchip MPLAB C Compiler for PIC32 MCUs (C32). On the PIC32MX5XX/6XX/7XX family devices, such as the PIC32MX795F512L device used on the PIC32 Ethernet Starter Kit, wrong values could be returned, regardless of the compiler optimization level. Known Problems: 1. Telnet ( see page 485) server module does not implement a lot of Telnet ( see page 485) functions. As a result, it will likely not display correctly or work at all with some Telnet ( see page 485) clients. The server was tested with the Microsoft telnet.exe utility which is provided with Microsoft Windows. 2. If the DHCP client and DHCP server are used at the same time and you connect ( see page 168) two similar boards to each other (ex: two PICDEM.net 2 boards connected via a crossover cable), a race condition can occur where both nodes will disable their DHCP server and neither board will get a successful DHCP lease. If this unlikely scenario occurs, as a work around, simply reset one of the boards to reenable it's DHCP server. 3. HI-TECH PICC-18 compilers are not supported in this release. The supplied HI-TECH PICC-18 MPLAB projects usually will not compile and/or link. 4. LCDBlocking.c timing for the LCD_E_IO enable signal is too fast to meet published data sheet limits for various LCD controllers when compiling for a PIC32 running at > 43MHz. Despite this potential timing violation, the LCD does normally work correctly on the precompiled PIC32 demos for the Explorer 16 at 80MHz.
****** v5.20 18 November 2009 ****** Changes: 1. Added PIC32MX7XX/6XX Family integrated Ethernet controller support. The "TCPIP PIC32 ETH Demo App" folder was added to compile for the PIC32 Ethernet Starter Kit. Ethernet driver files "ETHPIC32ExtPhy.c" and "ETHPIC32IntMac.c" were added, in addition to the "ETHPIC32ExtPhyDP83848.c" file, which is a specific driver file for the National DP83848 15
3 10/100 PHY.
2. Added RFC 3927 Auto IP module. This module will automatically assign a local IP address to the node in the 169.254.xxx.xxx private address range (subnet mask 255.255.0.0) if a DHCP server is not present on the network or the DHCP client is disable. The exact IP address chosen will be pseudo-random, but as required by the protocol, it will perform gratuatous ARPs to avoid clobbering anyone else's IP address. Also, unless there is an address collision with a preexisting node on the network, the IP address generated by the Auto IP module will not change between power cycle events (random number generator is seeded by local MAC address). To enable this module, STACK_USE_AUTO_IP must be defined in TCPIPConfig.h. When compiled in, the module defaults to enabled, but will automatically yield to the DHCP client module, which has higher priority. 3. Added "TCPIP MDD Demo App" beta application projects. Projects in this folder store the HTTP2 web pages in external FAT16/FAT32 formatted SD card or USB Mass Storage media instead of an MPFS2 formatted EEPROM or SPI Flash. For more information on these projects, see the "Running the TCPIP MDD Demo App (Beta Release).pdf" file in the MicrochipHelp folder. 4. Expanded XEEReadArray() API's third length parameter from a BYTE to a WORD. 5. Converted all variable declarations and type casts of TICK data type to DWORD. The TICK typedef is now deprecated and will be removed in a future stack release. This data type conflicts with the TICK structure used in certain other Microchip software libraries. 6. Added TCP_WINDOW_UPDATE_TIMEOUT_VAL ( see page 478) option to the TCP.c file (default 200ms). This timeout controls the time after calling TCPGet ( see page 450)() or TCPGetArray ( see page 451)() before the stack will transmit a RX window update to the remote node. Historically, the TCP_AUTO_TRANSMIT_TIMEOUT_VAL ( see page 478) value was used for this purpose (default 40ms). This change decreases the net window update transmission overhead. If this adversely affects your application RX performance (unlikely, but possible for certain communications patterns), set TCP_WINDOW_UPDATE_TIMEOUT_VAL ( see page 478) equal to or shorter than TCP_AUTO_TRANSMIT_TIMEOUT_VAL ( see page 478) to get the same or better behavior relative to previous stack versions. 7. Split TCP_MAX_SEG_SIZE configuration constant in TCP.c into separate TCP_MAX_SEG_SIZE_TX ( see page 481) and TCP_MAX_SEG_SIZE_RX ( see page 480) configuration constants. Previously, TCP_MAX_SEG_SIZE was used to limit both the maximum size of transmit and receive packets. In cases where large TX FIFOs are allocated, and the remote node advirtises a large Maximum Segment Size TCP option, this change improves TCP transmit performance by roughly 10%. 8. Renamed "Internet Radio App", "Internet Bootloader App" and "WiFi Iperf App" folders to "TCPIP Internet Radio App", "TCPIP Internet Bootloader App" and "TCPIP WiFi Iperf App" respectively. These new names ensure consistent folder placement when viewing the Microchip Solutions folder with other Microchip Application Libraries installed. Fixes: 1. Fixed SSL functionality (ex: HTTPS server) from failing when using the ENC424J600 and ENC624J600 Ethernet controllers. In stack versions 5.00 and 5.10, the BFSReg() and BFCReg() functions were being incorrectly used to set and clear CRYPTEN (EIR<15>). ENC424J600/624J600 silicon errata #6 on production silicon revision A2 prevents BFSReg() and BFCReg() from being able to modify CRYPTEN. This resulted in the SSL RSA encrypt/decrypt operations from ever finishing. The ENC424J600/624J600 errata #6 workaround is now implemented in the ToggleCRYPTEN() function in ENCX24J600.c. 2. Fixed an RSA padding error in the ENCX24J600.c's version of RSASetData() and RSASetE() functions. This fixes the Bad Record MAC problem when using SSL client APIs with the ENC424J600 and ENC624J600, as mentioned in the 5.10 stack release notes' Known Problems section. Although unknown at the time of release this problem also occurred in stack version 5.00. 3. Fixed DNS client from mishandling DNS responses that did not use name compression. Thanks go to Will Stone on the Microchip Ethernet forum for identifying this bug. 4. Fixed an ExtractURLFields ( see page 214)() API bug which would incorrectly parse the URLs containing other URLs. Ex: "http://www.google.com/search?q=http://www.microchip.com/" 5. Fixed TickGet ( see page 516)(), TickGetDiv256 ( see page 516)(), and TickGetDiv64K ( see page 517)() APIs from potentially returning an incorrect time value (0x10000 ticks less than it should have) on rare occasions when using a PIC32 and with compiler optimizations turned on. The Tick.c module was also revised so that the IEC0 register does not get written to via a load-modify-store operation on PIC32s so that it is now possible for other application ISR functions to write to IEC0 without risking state corruption. 6. Fixed PIC32 Starter Kit Debugger losing access to the PIC32 target when the project was run. JTAG was being disabled at run time, but the PIC32 Starter Kit Debugger requires JTAG to communicate with the debug executive. JTAG is now conditionally disabled on PIC32s when the __MPLAB_DEBUGGER_PIC32MXSK macro is undefined. 7. Fixed a Berkeley sockets API bug in which calling closesocket ( see page 168)() on a SOCK_STREAM ( see page 16
Microchip TCP/IP Stack Help 175) type socket (TCP) did not actually close the socket if the remote node did not first send a FIN to the local node. This would leak a TCP socket each time the affected API calling sequence occurred and result in no FIN getting transmitted to the remote node. 8. Fixed an HTTP2 filename parsing bug that would occur when a web browser submitted a request for a file with hex encoded characters in it. For example, with stack version 5.10 and Firefox 3.5.3, typing "http://mchpboard/%70rotect" into the URL field would have resulted in an HTTP 404 not found error when "http://mchpboard/protect/index.htm" should have been returned instead. Thanks go to Steve Tuttle for reporting this issue and suggesting a solution. 9. Fixed a Berkeley sockets API bug in which calling recvfrom ( see page 173)() on a datagram type socket (UDP) would return an incorrect remote IP address and port number when the from pointer was non-NULL. 10. Fixed HTTP2 server bug in which the HTTPReadPostName ( see page 244)() function was failing to convert the field name from URL encoding to plain-text. If the browser posted, for example, a field named "Stock Remaining", it would have been incorrectly returned from HTTPReadPostName ( see page 244)() as "Stock+Remaining". 11. In Stack 5.10, any new values you saved into AppConfig via the Network Configuration demo web page would have been mishandled for WiFi projects. HTTPPostConfig ( see page 90)() in CustomHTTPApp.c of the TCPIP WiFi Demo App and TCPIP Iperf Demo App projects were corrected so that they now write a magic 0x61 marker into EEPROM/SPI Flash address 0x0000 to inidicate that the AppConfig structure is valid in EEPROM/SPI Flash. This prevents the InitAppConfig() function in MainDemo.c from restoring the default settings when changing the values through the Network Configuration page. 12. For WiFi projects, a Gratuitous ARP Work-around was implemented to work around cases where access points send broadcast messages at data rates that the ZG2100 cannot listen ( see page 172) to. The define USE_GRATUITOUS_ARP (in TCPIPConfig.h) turns this feature on or off. Known Problems: 1. Telnet ( see page 485) server module does not implement a lot of Telnet ( see page 485) functions. As a result, it will likely not display correctly or work at all with some Telnet ( see page 485) clients. The server was tested with the Microsoft telnet.exe utility which is provided with Microsoft Windows. 2. If the DHCP client and DHCP server are used at the same time and you connect ( see page 168) two similar boards to each other (ex: two PICDEM.net 2 boards connected via a crossover cable), a race condition can occur where both nodes will disable their DHCP server and neither board will get a successful DHCP lease. If this unlikely scenario occurs, as a work around, simply reset one of the boards to reenable it's DHCP server. 3. HI-TECH PICC-18 compilers are not supported in this release. The supplied HI-TECH PICC-18 MPLAB projects usually will not compile and/or link. 4. ENC624J600 PSP modes 2, 4, 6, and 10 do not work at this time. Some Parallel Bit Bang modes may not work either. Some minor firmware changes are needed. 5. TCPIP ENCX24J600 Demo App-C18.mcp project does not compile by default using MPLAB C Compiler for PIC18 MCUs (C18) version 3.34. There is not quite enough program memory available on the PIC18F97J60 for the large number of selected stack features to allow linking. To get this project to compile, turn on compiler optimizations or disable one of the modules in TCPIPConfig.h (ex: comment out STACK_USE_DYNAMICDNS_CLIENT).
****** v5.10 29 July 2009 ****** Changes: 1. Added SSL capability to the Telnet ( see page 485) server. If STACK_USE_SSL_SERVER is defined, the Telnet ( see page 485) server will now listen ( see page 172) on port 992 for SSL secured connections. If you do not have a telnets client, you can use an SSL proxy, such as stunnel (http://www.stunnel.org/) to add SSL/TLS support to any telnet client. 2. Moved a number of string pointer tables in the HTTP.c, HTTP2.c, FTP.c, and DynDNS.c files to allocate in ROM instead of RAM. This reduces around 120 bytes of RAM usage in the HTTP2 server when compiled for the PIC18 or PIC24/dsPIC platforms. The gains are even greater on PIC32 platforms. 3. Added redefinition of SPIRAM*(), SPIFlash*(), and XEEPROM*() functions so that when compiled and used without proper HardwareProfile.h definitions, a more descript linker error will be generated instead of a mysterious symbol not found error. 17
ExtractURLFields ( see page 214)() in Helpers.c. This function provides an easy means of parsing an URL string and extracting the protocol, hostname, port, file path, etc. Currently, this function is commented out to save code space as no stack modules require it. However, it should work correctly if you simply uncomment it (remove the #if 0...#endif around it). strnchr ( see page 222)() in Helpers.c. Finds the first occurrence of a character within a string but limited to a maximum length before giving up. TCPPeek ( see page 457)() and TCPPeekArray ( buffer without removing the data from the stream. see page 457)() in TCP.c. Reads from a TCP socket's RX FIFO
TCPClose ( see page 445)() in TCP.c. Disconnects a socket from the remote node (if connected) and closes the socket handle, including for server type sockets. This function is identical to the TCPDisconnect ( see page 446)() API except for the handling of server sockets. TCPDisconnect ( see page 446)() returns server sockets to the listning state and maintains the socket handle. TCPClose ( see page 445)() closes the socket and frees all associated resources, invalidating the socket handle. 5. Updated the DHCP client module: Modified so that it wouldn't attempt to transmit DHCP Discover packets when the MAC layer reports no link (MACIsLinked() == FALSE). This avoids main() while(1) loop performance degredation when you unplug the Ethernet cable or lose association to your access point. Added capability of performing DHCP discovers and requests without setting the BOOTP broadcast flag. Now, the DHCP client module will start up and attempt to obtain an IP address with the broadcast flag set, but if it fails the next DHCP retry will attempt to obtain the IP address with the broadcast flag cleared. The flag will toggle back and fourth between unicast mode and broadcast mode if no DHCP server responds. This feature improves compatibility with certain DHCP servers and WiFi access points. Added several new APIs including DHCPInit(), DHCPIsEnabled(), DHCPStateChanged(), DHCPIsBound(), and DHCPIsServerDetected(). Removed the DHCPFlags DHCP_CLIENT_FLAGS global variable. Use the above named APIs now to get equivalent functionality. Removed the DHCPBindCount global variable. To detect if the DHCP state has changed, poll the new DHCPStateChanged() function. Removed the DHCPReset() API. To perform this operation, now call the DHCPInit() API. Use 0x00 for the vInterface parameter. 6. Removed deprecated TickGetDiff() macro. To get a tick difference, just subtract the two values in-line. This macro was removed because it promoted confusing code. Ex: a-b is different from b-a. However, it was not contextually obvious which of the two was returned when TickGetDiff(a, b) was called. 7. Added PIC32MX460F512L USB and dsPIC33FJ256GP710 PIM support to the Explorer 16 hardware profile for the TCPIP WiFi Demo App and WiFi IPerf App projects. 8. Added all files needed for SSL (assuming the crypto libraries are present) to the TCPIP WiFi Demo App-C30 and TCPIP WiFi Demo App-C32 projects. 9. Converted TCPIP Demo App, TCPIP WebVend App, Internet Radio App, and Internet Bootloader App MPLAB Build Directory Policy to compile in the project folder instead of the source folder. This reduces the depedancies on the MPLAB project include path and allows new projects to be created by copying one of the pre-existing folders (ex: copy "TCPIP Demo App" to "My App") without having problems including the wrong HardwareProfile.h and TCPIPConfig.h files. 10. Changed EEPROM/SPI Flash AppConfig record valid flag from 0x60 to 0x61 in the TCPIP WiFi Demo App and WiFi Iperf App projects. This will force the various EEPROM settings to get erased when switching between Ethernet and WiFi projects. This is done since the AppConfig structure changes when using WiFi (SSID string is added). 11. The Wifi Iperf App and TCPIP WiFi Demo App projects have been optimized for better performance. Fixes: 1. Fixed a TCPDisconnect ( see page 446)() API bug in which the last few bytes of data (up to the TCP socket's TX FIFO size less 532 bytes) was not transmitted and no FIN was sent out if the TX FIFO was full of data when TCPDisconnect ( see page 446)() was called. This problem could have only occurred for TCP sockets with a large TX FIFO (>=532 bytes). This problem could have been observed in stack version 5.00's "TCPIP Demo App-C32 EXPLORER_16 32MX360F512L ENC624J600 PSP 9.hex" precompiled application, among others, if you connected to the TCPPerformanceTest.c module and then attempted to simultaneously access the web server. The web server was returning data very slowly and failing to send the last parts of each file requested by the browser.
18
Microchip TCP/IP Stack Help 2. Eliminted a potential buffer overflow vulnerability from the HTTPHeaderParseContentLength ( see page 254)() function in HTTP2.c. If an oversized or malformed Content-Length header is sent from the web client, the function will now gracefully fail by returning an HTTP 400 Bad Request error page. Thanks go to Mark Philipp for identifying this error and suggesting a solution. 3. Fixed a TCPOpen ( see page 455)() problem in which the stack would continuously flood the network with nearly back-to-back ARP query packets if a client socket was created that specified a non-reachable remote IP address (ex: local gateway was offline, or for destinations on the same subnet, the actual remote node was offline). This problem would occur only after a few minutes (<10) had passed since the PIC was last reset. Thanks go to Sergey of DPS TELECOM for reporting this problem. 4. Fixed linking problem with BigInt_helpers.S (PIC24/dsPIC only) when targeting a PIC with more than 8KB of RAM. The interface registers (_iA, _xA, _iB, _xB, _iR, and _wC) are now forced into near RAM. 5. Cleaned up some uninitialized variable warnings in SNMP.c. 6. Fixed a sequence variable traversal bug in SNMP.c. 7. Cleaned up a large number of unsigned integer to signed integer comparison warnings produced by the MPLAB C Compiler for PIC18 MCUs (C18) version 3.32. With earlier versions of this compiler, these warnings would only be generated as messages, so they did not get displayed by default. 8. Some ENCX24J600 parallel bit bang modes work now. PSP Mode 5 indirect has been tested. 9. SSL client and server capabilities now work when using the ZeroG ZG2100M WiFi interface. In the 5.00 stack release, attempting to enable the STACK_USE_SSL_CLIENT or STACK_USE_SSL_SERVER TCPIPConfig.h options with this network controller would have resulted in an error trap. If an LCD was present, the LCD would display encRdPtrRAWId = encWrPtrRAWId when the error occurred. 10. The WiFi Iperf App demo locked up when an invalid command was entered at the serial port console. This is now fixed. 11. The WiFi Iperf App demo locked up when running with a PIC32 if iwconfig was typed at the serial port console. This is now fixed. 12. The Wifi Iperf App demo, when running on the PIC24 and PIC32, and compiled with the Os option (min code size optimization), did not work. This is now fixed. 13. Change a lot of BerkeleyAPI.c internals. This may fix a number of BSD API problems. 14. Fix a problem with SNMP variables being inaccessible with certain unique PEN numbers. Known Problems: 1. Telnet ( see page 485) server module does not implement a lot of Telnet ( see page 485) functions. As a result, it will likely not display correctly or work at all with some Telnet ( see page 485) clients. The server was tested with the Microsoft telnet.exe utility which is provided with Microsoft Windows. 2. If the DHCP client and DHCP server are used at the same time and you connect ( see page 168) two similar boards to each other (ex: two PICDEM.net 2 boards connected via a crossover cable), a race condition can occur where both nodes will disable their DHCP server and neither board will get a successful DHCP lease. If this unlikely scenario occurs, as a work around, simply reset one of the boards to reenable it's DHCP server. 3. HI-TECH PICC-18 compilers are not supported in this release. The supplied HI-TECH PICC-18 MPLAB projects usually will not compile and/or link. 4. ENC624J600 PSP modes 2, 4, 6, and 10 do not work at this time. Some Parallel Bit Bang modes may not work either. Some minor firmware changes are needed. 5. SSL client code doesn't work with ENC424J600/624J600 devices. The remote server terminates the connection reporting a bad record MAC (Message Authentication ( see page 86) Code). The SSL client does work with other controllers.
****** v5.00 27 April 2009 ****** Changes: 1. Added ZeroG ZG2100 802.11 WiFi controller support. The new TCPIP WiFi Demo App and WiFi Iperf App projects have 19
Microchip TCP/IP Stack Help been added, which default to using this controller. 2. Added Microchip ENC424J600/624J600 10/100 Ethernet controller support. Support for this controller is provided by the new ENCX24J600.c/.h files which perform the same role as the ENC28J60.c/.h or ETH97J60.c/.h files. Precompiled .hex files for the ENC624J600 controller require the use of the new Fast 100Mbps Ethernet PICtail Plus daughter card (AC164132). This product is not available at the time of the 5.00 TCP/IP stack release. However, it is anticipated to be available for purchase on www.microchipdirect.com in CQ3 2009. 3. Significantly updated the Internet Radio App project. Previously, radio stations were hard coded into program memory at compile time. Now, a dynamic Shoutcast directory client has been implemented which allows retrieval of radio stations at run time, offering endless stations you can tune into. The web pages for the radio have also been updated to allow control and status reporting of the board from a web browser. 4. Update SNMP Server (Agent) module to support SNMPv2C. The default Demo App web pages now include an SNMP reconfiguration capability to set the read and write community strings. 5. Added ICMPSendPingToHost ( see page 262)() and ICMPSendPingToHostROM ( see page 264)() APIs to ICMP (ping) client module. These two APIs are available only when STACK_USE_ICMP_CLIENT and STACK_USE_DNS is defined in TCPIPConfig.h. These functions allow pinging of DNS hostnames directly without the need for the application to convert the hostname to an IP address first by manually calling the DNS client APIs. With this addition, the PingDemo.c file was updated to ping the hostname "ww1.microchip.com" instead of a static IP address. Previously, the PingDemo ( see page 99) would stop working a couple of months after the stack was released, due to the IP address of the www.microchip.com server dynamically changing. If the DNS module is not enabled, the ping demo will instead ping the local gateway IP address instead of ww1.microchip.com. 6. Updated TCPPerformanceTest.c code. The previous version would generate incorrect speed calculations at high data rates (ex: >1Mbyte/sec). 7. Added multiple connection support to Telnet ( see page 485) server example module. To allow multiple connections, define MAX_SIMULTANEOUS_CONNECTIONS in Telnet.c greater than 1 and create an equal number of TCP_PURPOSE_TELNET type TCP sockets in the TCPSocketInitializer[] definition in TCPIPConfig.h. 8. Added more randomness to the local port selection when opening a client-mode TCP socket. This reduces the risk of reusing a previously used port number if the user power cycles the device. 9. Updated XEE* SPI EEPROM API functions. Writes are no longer required to start on an EEPROM page boundary, and writes can now be arbitrarily long without having to call XEEEndWrite() at each page boundary. Additionally, the XEEWriteArray() API has been added, which performs a similar operation to the SPIFlashWriteArray() API (but with no special erase cases to worry about). 10. Decoupled AppConfig storage in external SPI EEPROM or SPI Flash option from MPFS_USE_EEPROM and MPFS_USE_SPI_FLASH options. MainDemo.c will now save the AppConfig structure in external non-volatile memory, even if MPFS is unused (no HTTP or SNMP server modules enabled) or MPFS is using internal Flash program memory to store web pages/bib information. This change also allows the XEE*() and SPIFlash*() non-volatile read/write functions to be available at all times (even if MPFS is unused), as long as the appropriate hardware pinout definitions are present in HardwareProfile.h. SPI Flash and SPI EEPROM are no longer mutually exclusive with each other. However, if both are enabled simultaneously, AppConfig will be stored in the EEPROM, not the SPI Flash. 11. Added required SSL files to TCPIP Demo App MPLAB projects. SSL capabilities can now be turned on directly via the STACK_USE_SSL_SERVER and STACK_USE_SSL_CLIENT options in TCPIPConfig.h for these projects, assuming appropriate crypto libraries are installed (SW300052 available from https://www.microchipdirect.com/). With this change, the historical "SSL Demo App" folder has been removed. 13. Updated HardwareProfile.h files. This includes the addition of PIC18 Explorer board support, removal of the PICDEM Z profile, changes to the HI-TECH PICC-18 profiles for newer compilers, among other changes. 14. Added a TCP and UDP performance test measurements table to TCPIP Stack Help (TCPIP Stack Help.chm). Access this from the "Microchip TCP/IP Stack" book, "Stack Performance" page. 15. Updated MPFSlib project (Microchip.MPFS.dll file) so that C18 and C32 output from the MPFS2.exe utility is now identical for MPFS2 images. The generated .c file is now compatible with both C18 and C32 compilers simultaneously. Previously, the images generated for C18 would compile successfully for C32 projects, but would potentially operate incorrectly when compiler optimizations were turned on. Images generated for C32 would compile successfully and work on C18 projects, but the C18 compiler would take a very long time to process the file each time you rebuilt your MPLAB project. Now, the image generated for C18 matches the image generated for C32 and it will compile fast and work correctly on both platforms, even with compiler optimizations turned on. 16. Added schematics and BOMs for the Ethernet PICtail, Ethernet PICtail Plus, Fast 100Mbps Ethernet PICtail Plus, Internet Radio, PICDEM.net 2, and ZeroG ZG2100M PICtail development boards to the "MicrochipTCPIP StackDemo Board Files" folder. Fixes: 20
Microchip TCP/IP Stack Help 1. Fixed a denial of service vulnerability in the NBNSGetName ( see page 288)() function of the NBNS.c file. Previously, if a deliberately malformed packet was received, the PIC RAM could have become corrupted. Thanks go to David Talmage for finding this vulnerability. 2. Fixed Timer1 interrupt flag clearing code on PIC32 products. Previously, the Tick.c module was clearing the interrupt flag in an unsafe manner which could have corrupted other interrupt flags in the IFS0 register. Thanks go to Leon van Snippenberg working on the AVIX-RT RTOS for pointing this error out on the Microchip forums. 3. Fixed SNMP up-time variable. Previously the CustomSNMPApp.c module would respond with the number of Tick API ticks that elapsed, not the number of 10ms time slices that elapsed. The SNMP standard uses 10ms as its time base. 4. Fixed BigInt_helper.asm's _masBI() and _masBIROM() functions when the Br parameter's length modulo 4 was equal to 1 or 2. This bug previously caused the BigIntMod() function to sometimes go into an endless calculation loop on PIC18 products when using the SSL libraries and certain combinations of modulus data and length were used. Thanks go to Vasil Stoianov on the Microchip Ethernet forum for running into this defect and reporting it. 5. Fixed SSLSessionNew ( see page 429)() so that it wouldn't "lose" SSL sessions after waiting a few hours. This would previously make it impossible to make new SSL connections after a while, but then after a few more hours, the sessions would become free again. Thanks go to Jim Stephens for identifying this issue and finding the solution. 6. Fixed an SSL 2.0 antique client hello record length calculation bug occurring when a received record was > 255 bytes. 7. Added retransmission capability to SendNotification ( see page 113)() function in CustomSNMPApp.c. Previously, if an SNMP trap were sent, but the initial ARP query or response was lost on the network, the SendNotification ( see page 113)() code would have deadlocked, and suppressed all future transmission of SNMP traps. 8. Fixed DNS client timeout if the DNS server is unable to be ARPed. Previously, the DNS client would retry ARPing the DNS server indefinitely if it was offline. Now, the DNS client will correctly abort if too many attempts to ARP the DNS server fail. Thanks go to Phil "andersop" on the Microchip Ethernet forum for identifying this error. 9. Suppressed transmission of a TCP RST packet to an unknown IP or MAC address if the TCPDisconnect ( see page 446)() function was called on a client mode socket that was not finished with ARP or DNS resolution yet. Thanks go to Phil "andersop" on the Microchip Ethernet forum for pointing this behavior out. 10. Fixed TCP socket from disconnecting if the remote receive window was zero and TCPFlush ( called. Thanks go to Bob Topper for identifying this issue and suggesting a solution. see page 450)() was still
11. Fixed Tick.c module returning incorrect values when TickGet ( see page 516)() or other API was used with compiler optimizations turned on. Wrong values were observed when using MPLAB C Compiler for PIC24 MCUs and dsPIC DSCs version 3.12. 12. Fixed a number of SPI communications problems that could occur when compiler optimizations were turned on. The ENC28J60 was observed to not work correctly on the dsPIC33FJ256GP710 processor when compiled with MPLAB C Compiler for PIC24 MCUs and dsPIC DSCs version 3.12. 13. Fixed possible MPFS2 error when using an ASM30 .s image where MPFS_Start would be read using the wrong PSVPAG setting. You must rebuild your MPFS2 image file (ex: MPFSImg2.s) with this stack version's MPFS2.exe utility to get this correction applied. Known Problems: 1. Telnet ( see page 485) server module does not implement a lot of Telnet ( see page 485) functions. As a result, it will likely not display correctly or work at all with some Telnet ( see page 485) clients. The server was tested with the Microsoft telnet.exe utility which is provided with Microsoft Windows. 2. If the DHCP client and DHCP server are used at the same time and you connect ( see page 168) two similar boards to each other (ex: two PICDEM.net 2 boards connected via a crossover cable), a race condition can occur where both nodes will disable their DHCP server and neither board will get a successful DHCP lease. If this unlikely scenario occurs, as a work around, simply reset one of the boards to reenable it's DHCP server. 3. HI-TECH PICC-18 compilers are not supported in this release. The supplied HI-TECH PICC-18 MPLAB projects usually will not compile and/or link. 4. ENC624J600 PSP modes 2, 4, 6, and 10 do not work at this time. Parallel Bit Bang mode does not work either. Some minor firmware changes are needed.
****** SSL Note: RSA.c and ARCFOUR.c have not changed between the 4.50 and 4.55 releases. Although the precompiled SSL Demo App .hex files will differ, you can continue to use the previous TCP/IP Stack v4.50 Encryption Add-on with this 4.55 stack version. Changes: 1. Added DNS client support for a secondary DNS server address. Previously, the AppConfig.SecondaryDNSServer setting was unused. Now, the DNS client module will automatically swap the AppConfig.PrimaryDNSServer and AppConfig.SecondaryDNSServer values after any DNS query timeout (or ARP timeout for the DNS server) and attempt the query with the alternative server. If AppConfig.SecondaryDNSServer is disabled by setting it to the IP address 0.0.0.0, the DNS client will only use the AppConfig.PrimaryDNSServer value and never swap the values. With this change, the DHCP client was also updated. If the DHCP server does not specify a secondary DNS server, then the DHCP client will now set the AppConfig.SecondaryDNSServer value to 0.0.0.0. Previously, it would change the AppConfig.SecondaryDNSServer setting only if the remote DHCP server offered a secondary DNS server. Fixes: 1. Updated Internet Bootloader App project to correctly detect if the configuration bits are being changed or not. Previously, the bootloader always thought the configuration bits were being changed and thus had to always erase the last Flash page (largest memory address) twice for each firmware update. This did not cause any functional problems or specification violations, but it would decrease the effective Flash endurance of the last page. 2. Fixed a TCP socket memory corruption bug that would occur if TCPGetRemoteInfo ( see page 451)() API was called twice with different socket handles without an intermediate call to any other TCP API that takes a TCP_SOCKET ( see page 466) input. Thanks go to Bob Topper for identifying this problem and suggesting a solution. 3. Fixed the UDPIsGetReady ( see page 527)() function so that it returns the number of bytes remaining in the packet based on the current read location. This is the same behavior as stack versions 4.18 and earlier. In stack versions 4.50 and 4.51, the UDPIsGetReady ( see page 527)() function would always return the total number of bytes in the current packet, regardless of how many bytes the read pointer had been advanced through the UDPGet ( see page 526)() and UDPGetArray ( see page 527)() functions. Thanks go to Bob Topper for identifying this problem and suggesting a solution. 4. Fixed demo admin web page in TCPIP Demo App project so that the last byte of the MAC address can be changed, independent of the format it was entered by the user. 5. Fixed a buffer overflow bug that would occur when using the SSL server during hashing of the server certificate for the initial handshake. This error previously caused several bytes of random variables elsewhere in the project to get overwritten for each SSL connection. 6. BSD sockets API was updated to fix some issues. 7. LCDBlocking.c was updated to relax start up timing. This timing fix is specifically needed to support Explorer 16 boards with a Truly TSB1G7000 display (Novatek NT7603H controller). 8. Removed four uses of Arial Black font in MPFS2.exe utility. On some rare PC configurations, the use of this font caused the executable to not run. Known Problems: 1. Telnet ( see page 485) server module does not implement a lot of Telnet ( see page 485) functions. As a result, it will likely not display correctly or work at all with some Telnet ( see page 485) clients. The server was tested with the Microsoft telnet.exe utility which is provided with Microsoft Windows. 2. If the DHCP client and DHCP server are used at the same time and you connect ( see page 168) two similar boards to each other (ex: two PICDEM.net 2 boards connected via a crossover cable), a race condition can occur where both nodes will disable their DHCP server and neither board will get a successful DHCP lease. If this unlikely scenario occurs, as a work around, simply reset one of the boards to reenable it's DHCP server. 3. HI-TECH PICC-18 projects may not compile when targeting the external ENC28J60 chip on the PICDEM.net 2 development board (instead of the internal Ethernet controller). This problem only applies when a PIC18F97J60 family part is the target. I.e. it compiles correctly for the HPC_EXPLORER + Ethernet PICtail. 4. MAC.h RXSIZE precompiler test for proper range doesn't work. This is not a functional problem, just a compile-time configuration test. Ensure that you don't over allocate TCP_ETH_RAM_SIZE or MAX_HTTP_CONNECTIONS. 5. HI-TECH PICC-18 STD 9.51PL1 cannot compile DynDNS.c. It raises an "inconsistent type" error while trying to perform a ROM pointer to integer cast. The older 9.50PL3 compiler release is required to compile this file. 6. HI-TECH PICC-18 STD 9.50PL3 does not initialize several static variables correctly on reset. This behavior breaks many 22
Microchip TCP/IP Stack Help stack modules in the TCPIP Demo App and TCPIP WebVend App projects. Additionally, string printing functions do not work correctly, so the supplied "TCPIP Demo App-HITECHPICC18 PICDEMNET2 18F97J60.hex" and "TCPIP WebVend App-HITECHPICC18 PICDEMNET2 18F97J60.hex" files may not correctly print the board's DHCP assigned IP address on the board's LCD (if present) and UART. To avoid these severe problems, use the Microchip MPLAB C Compiler for PIC18 MCUs. A free student edition can be downloaded from http://www.microchip.com/c18.
****** v4.51 24 July 2008 ****** IMPORTANT NOTE: You must use MPLAB 8.10 or higher to successfully open the MPLAB projects. SSL Note: RSA.c and ARCFOUR.c have not changed between the 4.50 and 4.51 releases. Although the precompiled SSL Demo App .hex files will differ, you can continue to use the previous TCP/IP Stack v4.50 Encryption Add-on with this 4.51 stack version. Changes: None. This release includes bug fixes only. It is very important that applications using the ENC28J60 get fix item 7, below. Fixes: 1. TCPOpen ( see page 455)() was previously failing if you used it to start a connection with a remote hostname, but the DNS module failed to resolve the remote address on the first try. This, for example, would occur if you powered up your board and tried to connect ( see page 168) to a remote server before the Ethernet cable was attached. Once the Ethernet cable was attached, the socket would attempt to resolve and connect ( see page 168) to a garbage address. The Internet Radio application would sometimes not begin playing the default station upon power up because of this problem. 2. Set SEQ.ACK = 0 for outbound TCP SYN packets. This fixes a connection compatibility problem with certain paranoid TCP/IP stacks that would validate this field even though the ACK flag was clear. This problem would previously cause the Microchip TCP/IP stack to be unable to connect ( see page 168) client-mode TCP sockets to certain rare servers/services. Thanks go to Jean LE TUTOUR for finding one of these problem servers. 3. MPFSOpen ( see page 278)() and MPFSOpenROM ( see page 279)() for MPFS2 could leak a file handle if a name hash matched but no complete file name did. This has been corrected to prevent potential DOS attacks on the HTTP2 web server. Thanks to David Tan on the Microchip Ethernet formus for identifying this issue. 4. Fixed a bug in MPFS2.1 that caused compile errors when MPFS Classic images were generated for ASM30 containing files whose length was either zero or a multiple of 12. 5. Fixed an issue in HTTPPostConfig ( see page 90)() that caused it to ignore the flag that was set when invalid IP address input was detected. This issue only affects the example configuration page and only exists in v4.50 (prior versions functioned correctly). Also corrected an issue where user input could potentially overflow into part of the shadow AppConfig in the same function. Thanks to prinz3nroll3 on the Microchip Ethernet forums for identifying both of these issues. 6. Implemented Explorer 16 development board 5V LCD errata workaround to LCDBlocking.c. This corrects the A/D converter from returning erratic readings on certain Explorer 16 boards. LCD I/O pins are now continuously driven by the microcontroller instead of going high impedance when idle. 7. Fixed a critical ENC28J60 revision B7 errata workaround problem in the ENC28J60.c, MACFlush() function. Previously, the code was checking for an EREVID register value of 0x07 for silicon revision B7. This was incorrect. Silicon revision B7 actually has an EREVID value of 0x06. Note that this problem was caused by an incorrect EREVID value published in DS80349A, the B7 silicon errata documentation. Make sure to use DS80349B or later. Known Problems: 1. Telnet ( see page 485) server module does not implement a lot of Telnet ( see page 485) functions. As a result, it will likely not display correctly or work at all with some Telnet ( see page 485) clients. The server was tested with the Microsoft telnet.exe utility which is provided with Microsoft Windows. 2. If the DHCP client and DHCP server are used at the same time and you connect ( see page 168) two similar boards to each other (ex: two PICDEM.net 2 boards connected via a crossover cable), a race condition can occur where both nodes will disable their DHCP server and neither board will get a successful DHCP lease. If this unlikely scenario occurs, as a work around, simply reset one of the boards to reenable it's DHCP server. 23
Microchip TCP/IP Stack Help 3. HI-TECH PICC-18 projects may not compile when targeting the external ENC28J60 chip on the PICDEM.net 2 development board (instead of the internal Ethernet controller). This problem only applies when a PIC18F97J60 family part is the target. I.e. it compiles correctly for the HPC_EXPLORER + Ethernet PICtail. 4. MAC.h RXSIZE precompiler test for proper range doesn't work. This is not a functional problem, just a compile-time configuration test. Ensure that you don't over allocate TCP_ETH_RAM_SIZE or MAX_HTTP_CONNECTIONS. 5. HI-TECH PICC-18 STD 9.51PL1 cannot compile DynDNS.c. It raises an "inconsistent type" error while trying to perform a ROM pointer to integer cast. The older 9.50PL3 compiler release is required to compile this file. 6. HI-TECH PICC-18 STD 9.50PL3 does not initialize several static variables correctly on reset. This behavior breaks many stack modules in the TCPIP Demo App and TCPIP WebVend App projects. Additionally, string printing functions do not work correctly, so the supplied "TCPIP Demo App-HITECHPICC18 PICDEMNET2 18F97J60.hex" and "TCPIP WebVend App-HITECHPICC18 PICDEMNET2 18F97J60.hex" files may not correctly print the board's DHCP assigned IP address on the board's LCD (if present) and UART. To avoid these severe problems, use the Microchip MPLAB C Compiler for PIC18 MCUs. A free student edition can be downloaded from http://www.microchip.com/c18.
****** v4.50 02 June 2008 ****** IMPORTANT NOTE: You must use MPLAB 8.10 or higher to successfully open the MPLAB projects. Also, ensure that the latest C compiler is used. This release was tested against MPLAB C Compiler for PIC18 MCUs version 3.20, MPLAB C Compiler for PIC24 MCUs and dsPIC DSCs version 3.10, MPLAB C Compiler for PIC32 MCUs version 1.01, and HI-TECH PICC-18 version 9.50PL3 (STD). Earlier compilers may not be able to compile this TCP/IP stack release. Changes: 1. Added SSL 3.0 client capabilities, including SMTP over SSL. The SSL modules supports up to 1024-bit RSA handshakes and 128-bit ARCFOUR bulk encryption. This can be demonstrated using the SMTP client. SSL server support is functional, but a key generation utility is not yet provided and support over HTTPS is not yet reliable with all browsers. IMPORTANT: Encryption software is covered by US Export Control law, so it is not directly downloadable from the Microchip website. To use the encryption modules, you must order SW300052 from microchipDIRECT [ https://www.microchipdirect.com/ ] and install the required libraries. 2. Added Berkeley Sockets ( see page 149) Distribution (BSD) API translation layer. You can now call the well know Berkeley APIs instead of or in addition to the Microchip specific APIs. To use this new functionality, define STACK_USE_BERKELEY_API and configure BSD_SOCKET_COUNT in TCPIPConfig.h. Three new source code demos are provided to demonstrate this API: BerkeleyTCPClientDemo.c, BerkeleyTCPServerDemo.c, and BerkeleyUDPClientDemo.c. The TCP client demo is identical to the GenericTCPClient.c demo, but implemented using Berkeley Sockets ( see page 149). The UDP client demo is similarly identical to the SNTP.c client. The TCP server demo listens on TCP port 9764 and will echo any traffic received back to the sender. It allows up to 3 simultaneous connections when there are an adequate number of sockets defined in the TCPSocketInitializer[] array in TCPIPConfig.h. 3. Added support for Dynamic DNS services. See the Dynamic DNS Client module in the TCP/IP Stack Help for details. Presently, dyndns.org, dyndns.com, no-ip.com, and dns-o-matic.com are supported. 4. Added the Microchip TCP/IP Configuration Wizard to the Utilities folder, facilitating easier configuration of the TCP/IP Stack through a graphical application. 5. Restructured TCPIPConfig.h to remove rule-enforcement logic, placing the removed sections in TCPIP.h. Many other project structure changes were also made to clean up the general distribution appearance. 6. Increased DHCP Server default lease duration to 60 seconds instead of 15 seconds. Some computers were losing their IP lease before performing a renew operation with only a 15 second lease. 7. Removed CLOCK_FREQ, INSTR_FREQ, and PERIPHERAL_FREQ macro definitions. GetSystemClock(), GetInstructionClock(), and GetPeripheralClock() now return these respective values. This change was made for compatibility with other Microchip software libraries. 8. Added TCP Fast Retransmission capability. Whenever three duplicate ACK packets arrive, the stack will now immediately perform a retransmit operation. This greatly improves recovery latency whenever the network loses a packet for applications that stream TX data using TCP. 9. Improved TCP Keep Alive mechanism to automatically close TCP sockets which do not receive any keep-alive responses 24
Microchip TCP/IP Stack Help for TCP_MAX_UNACKED_KEEP_ALIVES ( see page 481) (default 6) times. This means that, by default, any connection that catastrophically breaks without notifying us (ex: user unplugs cable, Internet connection goes down, etc.) will time out and automatically close after 60 seconds (TCP_MAX_UNACKED_KEEP_ALIVES ( see page 481) * TCP_KEEP_ALIVE_TIMEOUT ( see page 480)). Server oriented sockets will return to the listening state. Client oriented sockets will close, but the TCP_SOCKET ( see page 466) handle will continue to remain valid until the application calls TCPDisconnect ( see page 446)(). Applications can check if the socket became disconnected and reset by calling TCPWasReset ( see page 462)() or TCPIsConnected ( see page 453)(). Note that this keep alive implementation will only close sockets that are broken (remote node is not responding to TCP requests). It will not close or otherwise interfere with idle connections in which the application is not transmitting or receiving data and wishes to keep the connection open. 10.Added a TCP RX SYN queue of depth TCP_SYN_QUEUE_MAX_ENTRIES ( see page 484) (default 3). This queue automatically saves incoming SYN packets destined for a local server port which is already connected to a different client. When the client disconnects, the SYN data is pulled out of the queue and the socket immediately attempts to connect ( see page 168) to the next client. This improves connect ( see page 168) time performance since the remote client no longer has to retransmit the SYN request if it was unserviceable the first time around. This is most apparent with the HTTP/HTTP2 servers which previously performed poorly with certain modern web browsers which attempt to open many simultaneous connections to the web server, such as Mozilla Firefox 3 beta 5 and Apple Safari 3.1. Entries in the queue automatically time out after TCP_SYN_QUEUE_TIMEOUT ( see page 484) (default 3 seconds) so as to prevent the queue from filling up permanently if several connection requests arrive for a service that is in use and will not be available for an extended period. 11.Modified the structure of the MPFS2 FAT (now known as MPFS2.1) to include name hashes first. This speeds up opening files by 25%, and makes opening index files nearly instant. 12.Updated the MPFS2 Utility. MPFS2.1 now supports the new FAT structure and provides a cleaner interface. It also writes images to disk as they are created, which eliminates the IndexOutOfBounds exceptions some users had reported. Finally, uploads are now truly multi-threaded. 13.Source code to the MPFS2.exe PC utility is now released. Find it in the Microchip SolutionsMicrochipTCPIP StackUtilitiesSourceMPFS21 folder. This project is designed to compile with Microsoft Visual C# 2008 Express Edition. 14.Added support for SST25VFxxxB serial flash parts in 2, 4, 8, 16, and 32Mbit densities. These parts can be used to replace EEPROMs for storing MPFS images (both versions) and custom data. 15.Added HTTPReadPostName ( see page 244), HTTPReadPostValue ( see page 245), and HTTPReadPostPair ( see page 245) functions to facilitate easier processing of data arriving via POST. 16.Split HTTPAuthenticate API into separate functions: HTTPNeedsAuth ( see page 242) and HTTPCheckAuth ( see page 238). This function was already split internally, and didn't make sense as a single API. 17.Updated DHCP client to close its UDP socket when idle (bound state) to save a small amount of resources. 18.Removed LED_IO macro from all hardware profiles because it is not suitable for use on certain hardware platforms that have non-contiguous LEDs or reversed bit ordering. Use the new LED_GET() and LED_PUT(val) macros to read and write to all of the LEDs at once. 19.Added Ethernet Hash Table Calculator.exe to the Utilities folder and start menu. This tool will calculate the correct bit that you must set in the EHT0-EHT7 registers on the ENC28J60 and PIC18F97J60 family devices for using the Hash Table RX filter. This is useful only for fixed MAC addresses known at design time. For addresses that are known at run time, use the SetRXHashTableEntry() function in the ENC28J60.c or ETH97J60.c files to set the correct EHT0-EHT7 bit. Fixes: 1. Fixed a buffer overflow data corruption issue in the FTP module that arises when too many parameters were passed on the command line. 2. Moved TCPWasReset ( see page 462) checking in HTTP2 to execute for every socket on every loop. Previously, it would only execute when a socket reconnected, which caused the RX buffer to not resize until after data was received. Some platforms (notably FF2 on Ubuntu) would stall if the initial advertised RX window was too small, and this change corrects that issue. 3. Updated SendSystemReset() and MACInit() initialization routine in ENC28J60.c. Previously, if the ENC28J60 was placed into sleep mode by calling MACPowerDown(), the SendSystemReset() command would not work anymore. This would leave the ENC28J60 in power down if the host PIC was ever reset. SendSystemReset() should work for all conditions with this update. Thanks go to Rob Haverkort on the Microchip Ethernet forum for identifying this problem. 4. Fixed an alignment bug in HTTP2 that caused redirects to fail when the MPFS2 image was stored in Flash program memory. Thanks to Todd Boaz on the Microchip Ethernet forum for identifying this bug, and Chen Qu for posting a solution. 5. Fixed SNTP client from losing accuracy if you called SNTPGetUTCSeconds ( see page 371)() 10s of thousands of times since the last server synchronization. Thanks go to "pic123" on the Microchip Ethernet forum for noticing this error. 6. Fixed a TickGet ( see page 516)*() API problem where the returned tick value could be off by 64K ticks occasionally on PIC24, dsPIC30/33, and PIC32 processors. This bug was previously fixed in stack versions 4.13 and 4.16, but it was 25
Microchip TCP/IP Stack Help unintentionally recreated in 4.18 due to PIC32 changes. 7. Fixed UART2TCPBridge module from failing to connect ( USE_REMOTE_TCP_SERVER was defined. see page 168) to a remote server when
8. Fixed an issue that prevented SNMP SETs on 16 and 32 bit parts when using MPFS2. Thanks go to Milena K on the Microchip Ethernet forum for identifying this problem. 9. Fixed a rare buffer corruption issue that could occur with UDP if TCP was also enabled. 10.Fixed a Tick rollover error in HTTP2. Thanks go to Paul Bixel on the Microchip Ethernet forum for identifying this problem. 11.Fixed an MPFS2 bug in which an excessive value to MPFS_SEEK_REWIND may have failed to return an error. Thanks go to Paul Bixel on the Microchip Ethernet forum for identifying this problem as well. 12.SMTP Client now sends EHLO when using authentication. Previously, the HELO command was used, even with authentication enabled. Using HELO with authentication creates incompatibilities with certain SMTP servers. 13.Improved Internet Bootloader robustness by retransmitting ACKs in response to data retransmissions by the remote sending node. Previously, if an ACK packet was lost before reaching the sending node, the TFTP upload would fail and need to be restarted. Thanks go to "coolvibe" Dave Collier on the Microchip Ethernet forum for identifying this behavior. 14.Fixed TFTP Internet Bootloader from not being accessible from Linux TFTP clients which were setting the IP header "Don't Fragment" flag bit. 15.Changed TCP so that unsent data that is automatically flushed by the TCP_AUTO_TRANSMIT_TIMEOUT_VAL ( see page 478) timer includes the PSH flag. This improves GUI responsiveness for certain applications which rely on this automatic flush feature, such as the UART2TCPBridge module. 16.Fixed TCP socket loss issue which could occur if the TCP TX FIFO size was greater than 536 bytes (TCP_MAX_SEG_SIZE). Before the fix, the socket would have gotten tied up indefinitely performing retransmissions every 1.0 seconds without detecting that the remote node was disconnected. 17.Fixed TCP socket hang issue that would occur if the PIC sent out a FIN and the remote node never responded with a corresponding FIN. The socket would have gotten stuck indefinitely in the TCP_FIN_WAIT_2 state. Thanks go to Mr. Kyle Strickland with AW North Carolina for identifying this bug. 18.Fixed UDPSetRxBuffer ( see page 531)() function from not working if it was called before having called UDPGet ( see page 526)() or UDPGetArray ( see page 527)() at least once. 19.Fixed an offset error of +2 milliseconds being returned from TickConvertToMilliseconds ( see page 515)(). Thanks go to Andrs ("saturn") on the Microchip Ethernet forum for finding this error. Note that due to integer truncation during division, this function can be off by 0.2% or so, depending on the value returned by GetPeripheralClock(). 20.Updated DelayMs() macro for MPLAB C Compiler for PIC18s to work correctly when a large parameter was given. You should now be able to delay between 0 and 65535 milliseconds across all supported compilers without ending up with an unexpectedly short delay. Known Problems: 1. Telnet ( see page 485) server module does not implement a lot of Telnet ( see page 485) functions. As a result, it will likely not display correctly or work at all with some Telnet ( see page 485) clients. The server was tested with the Microsoft telnet.exe utility which is provided with Microsoft Windows. 2. If the DHCP client and DHCP server are used at the same time and you connect ( see page 168) two similar boards to each other (ex: two PICDEM.net 2 boards connected via a crossover cable), a race condition can occur where both nodes will disable their DHCP server and neither board will get a successful DHCP lease. If this unlikely scenario occurs, as a work around, simply reset one of the boards to reenable it's DHCP server. 3. HI-TECH PICC-18 projects may not compile when targeting the external ENC28J60 chip on the PICDEM.net 2 development board (instead of the internal Ethernet controller). This problem only applies when a PIC18F97J60 family part is the target. I.e. it compiles correctly for the HPC_EXPLORER + Ethernet PICtail. 4. MAC.h RXSIZE precompiler test for proper range doesn't work. This is not a functional problem, just a compile-time configuration test. Ensure that you don't over allocate TCP_ETH_RAM_SIZE or MAX_HTTP_CONNECTIONS. 5. HI-TECH PICC-18 STD 9.51PL1 cannot compile DynDNS.c. It raises an "inconsistent type" error while trying to perform a ROM pointer to integer cast. The older 9.50PL3 compiler release is required to compile this file. 6. HI-TECH PICC-18 STD 9.50PL3 does not initialize several static variables correctly on reset. This behavior breaks many stack modules in the TCPIP Demo App and TCPIP WebVend App projects. Additionally, string printing functions do not work correctly, so the supplied "TCPIP Demo App-HITECHPICC18 PICDEMNET2 18F97J60.hex" and "TCPIP WebVend App-HITECHPICC18 PICDEMNET2 18F97J60.hex" files may not correctly print the board's DHCP assigned IP address on the board's LCD (if present) and UART. To avoid these severe problems, use the Microchip MPLAB C Compiler for PIC18 MCUs. A free student edition can be downloaded from http://www.microchip.com/c18.
26
****** v4.18 28 November 2007 ****** Changes: 1. Added C32 and PIC32MX support. Some things were cleaned up in the process. 2. Removed linker scripts from C30 MPLAB projects. MPLAB IDE 8.00 can automatically select the correct linker script for 16-bit and 32-bit products. 3. Updated TCPPerformanceTest.c module. Now it automatically calculates the TX throughput and displays it for you. Also, there is now an RX throughput testing mode, which listens on a separate TCP socket (port 9763) when a TCP socket of type TCP_PURPOSE_TCP_PERFORMANCE_RX is allocated in TCPIPConfig.h. The RX socket is by default not enabled to save memory, so you must create a TCP_PURPOSE_TCP_PERFORMANCE_RX socket in TCPIPConfig.h and ensure that enough memory is allocated to accommodate it to test the RX performance test. When connected to port 9763, send a large amount of data and the PIC microcontroller will send back a count of how many bytes were received per second. 4. UDPPerformanceTest.c module now transmits 1024 packets on start up and then stops to prevent continually broadcast flooding your network. To transmit more packets after 1024 is reached, hold down BUTTON3 (left-most button on most boards). 5. Significantly improved the speed of the MD5 and SHA-1 functions. Gains for the 8-bit compilers were 50-75%, while 16-bit parts saw more modest improvements (~10%). 6. Reimplemented TCP_CLOSE_WAIT TCP state ("CLOSE WAIT" in RFC793). Now, TCP sockets that receive a FIN from the remote node will hold off transmitting a FIN back to the remote node until the TCP_CLOSE_WAIT_TIMEOUT ( see page 478) (defined at the top of TCP.c) elapses or immediately when the application calls the TCPDisconnect ( see page 446)() function. This makes it possible for the application to transmit a response back to the remote node before the socket becomes closed on our end. Similarly, it simplifies application usage of the last RX bytes received as these bytes are now assured to still be in the RX FIFO for at least TCP_CLOSE_WAIT_TIMEOUT ( see page 478) seconds. TCP_CLOSE_WAIT_TIMEOUT ( see page 478) defaults to 200ms in this stack version. 7. Pushed the SNTP requery on failure timeout up some. It was ~14 seconds and is now ~20 seconds. 8. Added TFTPOpenROMFile ( products. see page 498)() API to complement TFTPOpenFile ( see page 498)() when using PIC18
9. Added a fourth parameter to newAJAXCommand() in mchp.js, allowing data to be POSTed along with the AJAX request. 10.Deprecated the TCP Loopback functions, which includes TCPOpenLoopback, TCPCloseLoopback, TCPIsLoopback, TCPInject, and TCPSteal. These functions were added in 4.10 for future SSL support, but have since become unnecessary. They are of limited usefulness, and so are being removed to save code space. The functions are still available in this version, but will be removed in the next release. 11.Added SMTPClient.ServerPort ( see page 96) field to the SMTP API. This allows the remote server port number to be specified dynamically at run time instead of being hard coded to the SMTP_PORT ( see page 311) value defined at the top of SMTP.c. SMTP_PORT ( see page 311) is now only a default. 12.Added web interface to the SMTP module in the TCPIP Demo App applications. You can now configure the SMTP module and send emails directly from within your web browser. The HTTPPostEmail ( see page 91)() function in CustomHTTPApp.c also demonstrates how to send MIME encoded attachments in emails. The default demo will send button states, LED states, and the current potentiometer reading as a CSV file attached to the email. 13.Changed SMTPDemo ( see page 94)() in MainDemo.c to trigger on BUTTON2 and BUTTON3 simultaneously held down instead of BUTTON0 only. Fixes: 1. Fixed an ENC28J60.c MACGetArray() bug which would overwrite one byte of memory at address 0xFFFFFFFF if you provided NULL for the destination address pointer. 2. Fixed an MPFS2.c MPFSGet ( see page 272)() bug which would overwrite memory address 0x00000000 if a NULL pointer was provided as the destination. 3. Fixed a bug in the HTTP2 server accessing incorrect sockets if an inadequate number of sockets were available on POR. 4. Fixed Internet Bootloader project from failing with a timeout if an ARP packet arrived during the Erase/Write operation. 5. Fixed DHCP client RFC non-compliance where it would send the ciaddr field in the initial SELECTING state. Also, in the 27
Microchip TCP/IP Stack Help RENEWING state, the Requested IP Address ( see page 144) option was being sent, which is illegal. These changes may fix compatibility problems with certain DHCP servers. 6. Fixed TFTP Client's TFTPCloseFile ( see page 492)() function from sending data using a wrong UDP socket if StackTsk() was called after TFTPIsFileOpened ( see page 494)() was last called. 7. Added two zero bytes to the ICMP echo request payload to improve compatibility with some buggy NAT routers. Known Problems: 1. Telnet ( see page 485) server module does not implement a lot of Telnet ( see page 485) functions. As a result, it will likely not display correctly or work at all with some Telnet ( see page 485) clients. The server was tested with the Microsoft telnet.exe utility which is provided with Microsoft Windows. 2. If the DHCP client and DHCP server are used at the same time and you connect ( see page 168) two similar boards to each other (ex: two PICDEM.net 2 boards connected via a crossover cable), a race condition can occur where both nodes will disable their DHCP server and neither board will get a successful DHCP lease. If this unlikely scenario occurs, as a work around, simply reset one of the boards to reenable it's DHCP server. 3. HI-TECH PICC-18 projects may not compile when targeting the external ENC28J60 chip on the PICDEM.net 2 development board (instead of the internal Ethernet controller). This problem only applies when a PIC18F97J60 family part is the target. I.e. it compiles correctly for the HPC_EXPLORER + Ethernet PICtail. 4. MAC.h RXSIZE precompiler test for proper range doesn't work. This is not a functional problem, just a compile-time configuration test. Ensure that you don't over allocate TCP_ETH_RAM_SIZE or MAX_HTTP_CONNECTIONS.
****** v4.16 06 November 2007 ****** Changes: 1. Added Internet Radio application. This is a TCP client application which downloads streaming MP3 audio from a Shoutcast server and then plays it back to stereo earphones via a VLSI VS1011 audio decoder. 2. Added SPIRAM.c module. This module is intended for interfacing to an AMI Semiconductor N256S0830HDA SPI RAM chip. The TCP module can now interface directly to this SPIRAM module to store TCP socket FIFO buffers and other TCB data in the external RAM. 3. Added TCP_OPTIMIZE_FOR_SIZE ( see page 481) compile time configuration macro to TCP.c file. When optimizing for small code size, the TCP module ROM footprint shrinks up to 6KB, but performance may slow down on some processors (namely PIC18s, where the penalty is approximately 15%). 4. Added USE_EEPROM_25LC1024 compile time configuration macro to TCPIPConfig.h. Enable this definition if you are storing your MPFS[2] on a 1Mbit 25LC1024 or similar EEPROM device that uses 24-bit addressing and a 256 byte write page size. 5. Changed LCDBlocking.c module initialization code. It should now be possible to use 4-bit mode on certain "unusual" LCD controllers, like the Samsung S6A0032. Most PICDEM.net 2 and Explorer 16 boards use an LCD with this controller. 6. SNTP client now attempts to requery the SNTP server about every 14 seconds if the last query attempt fails. This allows the internal time value to become valid quickly should the board be powered up before an Ethernet cable is attached or if the DHCP client doesn't obtain an IP address quickly enough. Previously, it would take up to 10 minutes after plugging the Ethernet cable in to get a correct time value from the SNTP server. 7. Added UDP_USE_TX_CHECKSUM compile time configuration macro to TCPIPConfig.h. When enabled, all UDP packets will have a correct UDP checksum computed and inserted into the UDP header of outbound packets. If you do not define this macro, the UDP checksum will be disabled (left as 0x0000), which is how previous stack versions operated. Note that enabling checksum generation cuts your maximum UDP TX throughput by nearly half due to the required computations. 8. Substantially changed TCP socket RX and TX FIFO allocation. Now, sockets can be stored either in Ethernet RAM, PIC RAM, or external (SPI) RAM. Previously, sockets could only be allocated in Ethernet RAM, which was not scalable. 9. Added TCPOpen ( see page 455)() API function. This replaces TCPListen ( see page 455)() and TCPConnect ( see page 445)(). TCPOpen ( see page 455)() supports a large number of options that will make the creation of client mode sockets much easier. You can specify the remote node as a hostname that needs DNS and ARP resolution, an IP address that only needs ARP resolution, or legacy NODE_INFO pointer for direct compatibility with the previous 28
Microchip TCP/IP Stack Help TCPListen ( see page 455)() and TCPConnect ( see page 445)() APIs. TCPOpen ( see page 455)() also supports a socket type parameter which will allow you to use the new TCP socket RAM allocation system. 10.Added TCP Keep Alive mechanism defined by RFC 1122 section 4.2.3.6 to the TCP module. This helps automatically detect lost connections. If the remote node sends back an RST, this immediately closes the lost connection on our end. Currently, no action is taken if the keep alive gets no response. Note that this feature deviates from the standard by defaulting to only 10 seconds instead of over 2 hours. Also deviating from the standard, this feature is enabled by default. To disable it, undefine TCP_KEEP_ALIVE_TIMEOUT ( see page 480) at the top of TCP.c. 11.Moved TCPPerformanceTest.c module from default port 12345 to 9762. 12.Moved UDPPerformanceTest.c module from default port 12345 to 9, the "discard" protocol port. Fixes: 1. The DHCP client now specifically requests the previous IP address when a DHCP renewal occurs. 2. The SNTP client now correctly maintains time when repetitively calling SNTPGetUTCSeconds ( see page 371)() between an NTP requery event. Thanks go to Rob Haverkort on the Microchip Ethernet forum for noticing the time value incrementing far faster than it should have. 3. TCP module will not transmit a bunch of unnecessary duplicate ACK packets when data is ready to be transmitted but the remote RX window is zero. This previously didn't cause anything to break, but would waste CPU time and bandwidth sometimes. 4. TCP sockets will no longer automatically close if the remote RX window stays zero for several seconds. 5. Fixed TFTP Internet Bootloader project from corrupting the configuration fuses. Previously, this would result in the Watchdog timer being enabled and causing an unintentional reboot every few minutes with the demo TCP/IP stack. Known Problems: 1. Telnet ( see page 485) server module does not implement a lot of Telnet ( see page 485) functions. As a result, it will likely not display correctly or work at all with some Telnet ( see page 485) clients. The server was tested with the Microsoft telnet.exe utility which is provided with Microsoft Windows. 2. TFTPc module has not been tested with this version. 3. If the DHCP client and DHCP server are used at the same time and you connect ( see page 168) two similar boards to each other (ex: two PICDEM.net 2 boards connected via a crossover cable), a race condition can occur where both nodes will disable their DHCP server and neither board will get a successful DHCP lease. If this unlikely scenario occurs, as a work around, simply reset one of the boards to reenable it's DHCP server. 4. HI-TECH PICC-18 projects may not compile when targeting the external ENC28J60 chip on the PICDEM.net 2 development board (instead of the internal Ethernet controller). This problem only applies when a PIC18F97J60 family part is the target. I.e. it compiles correctly for the HPC_EXPLORER + Ethernet PICtail. 5. MAC.h RXSIZE precompiler test for proper range doesn't work. This is not a functional problem, just a compile-time configuration test. Ensure that you don't over allocate MAX_TCP_SOCKETS, TCP_TX_FIFO_SIZE, TCP_RX_FIFO_SIZE, or MAX_HTTP_CONNECTIONS.
****** v4.13 02 October 2007 ****** Changes: 1. Added command line support to the MPFS2.exe tool. You can now generate MPFS output files using batch scripts or other console applications. 2. Added dynamic variable parameter capabilities to the MPFS2 utility. To use, add the parameters you wish to pass to the end of the dynamic variable. All parameters are passed as WORD values. (ex: ~myArray(2,5)~ ) 3. Added TCPWasReset ( see page 462)() API to allow the application layer to be notified if an underlying socket reset has occurred (ex: remote node disconnects, cable is disconnected and times out, user calls TCPDisconnect ( see page 446)(), etc.). The reset state is latching, which allows the application layer to detect if a remote node disconnects and a new connection occurs on the same socket before the application can detect the original disconnection through the TCPIsConnected ( see page 453)() API. 29
Microchip TCP/IP Stack Help 4. Added a counter to the UDPPerformanceTest module and made it supress transmission if an Ethernet link is not present. 5. Added TCPIP WebVend App example application to the main stack distribution. This corresponds to three new Microchip Webinars being published on the HTTP2 server usage topic. Fixes: 1. Fixed MPFS2.exe PC utility from crashing if you attempt to generate an MPFS classic .bin/.c/.s output file. 2. Fixed RCONbits definition for HPC_EXPLORER hardware profile when using the HI TECH PICC-18 compiler. 3. Fixed a MPFSGetFilename ( see page 274)() bug when using C30 and MPFS2 images stored in program memory. Thanks to Billy Walton on the Microchip Ethernet forum for identifying this issue. 4. Fixed a TCP RX FIFO corruption problem which would occur if the remote node sent more data than could fit in our RX FIFO in a single packet. The GeneticTCPClient.c module was subject to experiencing this problem when connected to www.google.com's servers. 5. Fixed a DHCP client UDP socket leak if you called DHCPDisable() after the DHCP client had already obtained a UDP socket. Thanks go to Matthew Kendall on the Microchip Ethernet forum for identifying this problem. 6. Fixed a SNMP Server module bug testing a string length (with respect to SNMP_COMMUNITY_MAX_LEN ( see page 328)) being off by one, resulting in possible memory corruption. Thanks go to Matthew Kendall on the Microchip Ethernet forum for identifying this problem. 7. Cleaned up some C30 compiler warnings related to macro definitions with inadequate parenthesis in them. 8. Fixed HTTP2 module sometimes returning a 501 error instead of a correct web page when being bombarded with new connection requests. 9. Fixed a TickGet ( see page 516)*() API problem where the returned tick value could be off by 64K ticks occasionally on PIC24 and dsPIC processors. 10.Fixed SMTP client module failing to send email when attempting to send an email with a `CC' or `BCC' field that was in ROM while the `To' field was in RAM or visa versa. 11.Fixed TCP module sending an incorrect sequence number in RST packets sent when in the TCP_SYN_SENT state and an invalid segment arrives. In prior stack versions, some TCP client applications might take a very long time to recover in the event of a power failure, reset, and subsequent reconnect to a remote server that still thinks the old connection is still active. With this fix, reconnections should be possible almost immediately after a power failure because the correct RST packet will cause the old connection to get closed right away. 12.Fixed a TCP socket leak problem that would occur over if the local PIC called TCPDisconnect ( see page 446)() and the remote node didn't send us a correct FIN response. Sockets ( see page 149) could previously get lost in the TCP_FIN_WAIT_2 state and wouldn't recover unless the application called TCPDisconnect ( see page 446)() a second time with the same socket handle. Known Problems: 1. Telnet ( see page 485) server module does not implement a lot of Telnet ( see page 485) functions. As a result, it will likely not display correctly or work at all with some Telnet ( see page 485) clients. The server was tested with the Microsoft telnet.exe utility which is provided with Microsoft Windows. 2. TFTPc module has not been tested with this version. 3. If the DHCP client and DHCP server are used at the same time and you connect ( see page 168) two similar boards to each other (ex: two PICDEM.net 2 boards connected via a crossover cable), a race condition can occur where both nodes will disable their DHCP server and neither board will get a successful DHCP lease. If this unlikely scenario occurs, as a work around, simply reset one of the boards to reenable it's DHCP server. 4. HI-TECH PICC-18 projects may not compile when targeting the external ENC28J60 chip on the PICDEM.net 2 development board (instead of the internal Ethernet controller). This problem only applies when a PIC18F97J60 family part is the target. I.e. it compiles correctly for the HPC_EXPLORER + Ethernet PICtail. 5. HI-TECH PICC-18 projects will not correctly set the processor configuration fuses through code using the __CONFIG() macro. Ensure that the configuration fuses are manually set correctly via the MPLAB IDE Configuration Bits dialog. This problem has been observed with compiler version 9.50PL3. 6. MAC.h RXSIZE precompiler test for proper range doesn't work. This is not a functional problem, just a compile-time configuration test. Ensure that you don't over allocate MAX_TCP_SOCKETS, TCP_TX_FIFO_SIZE, TCP_RX_FIFO_SIZE, or MAX_HTTP_CONNECTIONS. 7. GenericTCPClient ( see page 95) example of downloading a web page from www.google.com is extremely slow. The default TCP socket has too little RX space to accept ( see page 166) a full packet sent from Google's servers, so the remote server must retransmit a lot of data, slowing the transfer down a lot. Making TCP_RX_FIFO_SIZE 536 bytes or 30
Microchip TCP/IP Stack Help bigger and correspondingly shrinking MAX_TCP_SOCKETS will correct this problem.
****** v4.11 27 August 2007 ****** IMPORTANT NOTE: You must use MPLAB 7.62 or higher to successfully open the MPLAB projects. Changes: 1. Added a Microchip TCP/IP Stack Users' Guide to document the stack features/modules/and APIs and address the stale AN833 documentation. Note that this is a work in progress. Many modules have yet to be documented in the Users' Guide. 2. Added HTTP2 module. This HTTP module includes a whole new API and supreme new features, such as POST support, cookies support, browser authentication support, and more. 3. Added MPFS2 module. This module is required for the new HTTP2 module and performs better while having fewer limitations. Long filenames and folders are now supported. 4. Added a new GUI based MPFS2.exe PC utility. The older MPFSv2.exe GUI application and MPFS.exe command line tool has been retired. The new utility has advanced features, such as MPFS2 file format support, GZIP compress, etc. 5. Added a TFTP bootloader. This is a stand alone project and currently only supports the PIC18F97J60 family of PIC processors with internal Ethernet. 6. Added UART2TCPBridge.c file and STACK_USE_UART2TCP_BRIDGE option to TCPIPConfig.h. This new module acts as a TCP and UART bridge, with a high priority UART interrupt and dedicated UART TX and RX FIFOs for minimum UART latency and maximum performance. By default, the bridge acts as a TCP server and listens on port 9761. The UART baud rate defaults to 19200. The bridge can be reconfigured to act as a TCP client. 7. Added Simple Network Time Protocol (SNTP) client. This module automatically obtains the current time (date) from the Internet. Enable this module by defining STACK_USE_SNTP_CLIENT in TCPIPConfig.h. Obtain the current time (in seconds since 00:00:00 1970) by calling the SNTPGetUTCSeconds ( see page 371)() API. 8. Added support functions Base64Encode ( see page 211)() and Base64Decode ( see page 211)() in Helpers.c. Base 64 is required for the new HTTP2 module, but of general use to many applications. 9. Added SMTP Authentication ( see page 86) support to the SMTP Client. To use this, set the SMTPClient.Username and SMTPClient.Password string pointers to a non-NULL value before calling SMTPSendMail ( see page 306)(). Applications implementing email transmission capabilities should expose these options to the end-user for configuration. To use SMTP servers that do not support the AUTH LOGIN authentication command, simply leave the SMTPClient.Username and SMTPClient.Password pointers as their default NULL value. 10.Converted DHCPDisable() from a macro to a real function and added the complementary DHCPEnable() function. These two functions can be used at run time to dynamically switch between using a static IP address and configuration and DHCP assigned IP address and configuration. 11.Updated StringToIPAddress ( see page 221)() to work more robustly, including the ability to decode host name strings and determine if they contain a valid IP address or not. Also, the complementary ROMStringToIPAddress ( see page 221)() function was added. 12.Updated the DNS module. Now, if you give it an IP address string to resolve, it will convert the string to an IP address and immediately return without querying the DNS. 13.Shrunk the advertised TCP Maximum Segment Size from 576 bytes to 528 bytes. This might improve compatibility if your TCP data has to propagate over nodes with small MTUs and you have a correspondingly large TCP RX FIFO defined. 14.Performed some maintenance on the FTP.c file. No significant functionality has been changed, but some potential problems were corrected. 15.Altered Tick.c file and API. Now, the Tick module can operate maximum precision, returning the value of the actual Timer as it is counting, without disturbing the timer count by writing to it or disabling it. Three new APIs were added, TickGetDiv256 ( see page 516)(), TickGetDiv64K ( see page 517)(), and TickConvertToMilliseconds ( see page 515)(). Internally the tick counter is now 48-bits wide and as accurate as your Timer clock source, allowing you to use it as a Real Time Clock. 16.Added PIC24FJ64GA004_PIM hardware profile. This hardware profile is intended for use with the PIC24FJ64GA004 PIM on the Explorer 16 development board. In this mode, BUTTON2 and BUTTON3 and several of the LEDs do not work correctly due to lack of I/O pins on this device. Also, you cannot have the POT and TEMP jumpers on the PIM bridged because these signals are multiplexed with the SDO1/SDI1 pins needed for the Ethernet PICtail Plus. 31
Microchip TCP/IP Stack Help 17.Removed most ROM APIs when using a 16-bit compiler (C30). PIC24s and dsPICs usually don't need separate ROM functions since the Program Space Visibility feature maps ROM into RAM space. All ROM APIs are still supported, but they are now macros to base RAM APIs. This change saves a couple of kilobytes of code space on PIC24 and dsPICs. 18.Improved MyTCB structure caching. This should reduce TCP packet processing overhead with the ENC28J60 where TCBs are stored in the Ethernet RAM. 19.MAX_RETRY_COUNTS TCP configuration option has been renamed to TCP_MAX_RETRIES ( see page 480). 20.FTP server is no longer enabled by default. HTTP2 now supports POST, so you can upload new webpages through the /mpfsupload page now. FTP required two precious TCP sockets. 21.Began adding hooks for an SSL/TLS transport for secure HTTPS and other future stack modules. Note that these cryptographic modules are not available at this time. Configuration options such as MAX_SSL_CONNECTIONS do nothing and should not be modified. 22.Username has changed for all of the modules. Now all modules have a default username of "admin" and password of "microchip". Previously, the FTP and Telnet ( see page 485) modules used "ftp" and "telnet" respectively for the usernames. Fixes: 1. Fixed a SendFile() bug in HTTP.c where parsing dynamic cgi files could send garbage back to the web browser sometimes. Thanks go to Matt Watkins on the Microchip Ethernet forum for identifying this issue. 2. Fixed an off by one error in the calculation of RESERVED_TCP_MEMORY. Previously, the last TCP socket's RX FIFO would incorrectly overlap with the Ethernet RX buffer, causing incoming packets to occasionally be corrupted or the incoming data on the last socket to get corrupted. 3. Fixed the QWORD_VAL's dword struct element types. dword.LD and dword.HD were incorrectly defined as WORDs instead of DWORDs. Thanks go to Iaki Esparza on the Microchip Ethernet forum for identifying this issue. 4. Fixed the incorrect processing of received IP fragments with a non-zero offset. This stack does not support IP packet reconstruction due to the limited amount of available RAM. Thanks go to Iaki Esparza on the Microchip Ethernet forum for noticing this behavior. 5. Board now only responds to ping requests to our IP address, the directed subnet broadcast address, or the broadcast address of 255.255.255.255. Previously, it would respond to any ping request to any IP address, assuming the MAC address was correct. 6. Fixed a memory corruption/UDP packet loss problem when handling incoming UDP packets. Previously, StackTask() would incorrectly continue processing more packets if it came upon a UDP packet. Thanks go to Iaki Esparza on the Microchip Ethernet forum for identifying this issue. 7. Fixed the SMTPClient.ROMPointers.Server flag having an inverted meaning. Previously, the SMTP client module would treat the SMTPClient.Server pointer as a ROM pointer if this bit was cleared. In most cases, this would cause the SMTP client to return an error code of 0x8000 when the SMTPClient.SMTPServer ( see page 311) address pointer was set. 8. Fixed the DHCP Server module from incorrectly parsing received packets which had a DHCP_PARAM_REQUEST_IP_ADDRESS option followed by more options. Previously due to the length miscalculation, the parser would enter a random state, depending on the packet's contents. Thanks go to Iaki Esparza on the Microchip Ethernet forum for identifying this issue. 9. Fixed potential incorrect results when UDPIsGetReady ( see page 527)() was called and a previous application did not call UDPDiscard ( see page 525)() on an RX packet. Now, StackTsk() calls UDPDiscard ( see page 525)() as appropriate to let it know when it's old RX data is being thrown away. This fixes a potential bug in the DHCP Server module and makes the UDP API more robust. Thanks go to Iaki Esparza on the Microchip Ethernet forum for identifying the potential DHCP server issue. 10.Fixed a potential ARP bug where the Gateway's MAC address would be returned for an IP address on the local subnet. This unusual case would occur when two application tasks were using the ARP module at the same time and the second application was trying to resolve an IP address off of our subnet. Thanks go to Iaki Esparza on the Microchip Ethernet forum for pointing this issue out. 11.Fixed an PIC18F97J60 family MAC layer bug where MACGetArray() might not correctly increment the Ethernet read pointer if a NULL pointer was given for the destination. The C compiler might have optimized the function so that it would increment the read pointer one less than it was supposed to. 12.The TCP module now acknowledges TCP Keep-Alive packets which will help prevent connection loss if the remote node fills up our RX FIFO and then our window-update packet gets lost on the network/Internet. In stack version 4.02, a zero-window probe would have been required to restore the communications. 13.Fixed a TCP RX FIFO corruption issue that would occur in (uncommon) circumstances when too many out-of-order segments arrived such that a second "hole" would have been required to accommodate the data. Thanks go to Iaki Esparza and his eagle eyes on the Microchip Ethernet forum for finding this corner case bug. 14.Inline assembly in the ETH97J60.c file has been modified to accommodate the C18 Extended mode and C18 Auto default storage class. Previously, the Ethernet module would transmit garbage packets when using the C18 32
Microchip TCP/IP Stack Help parameter stack. 15.Fixed potential buffer overflow in NBNS.c's NBNSGetName ( see page 288)() function where an unexpected string length retrieved from the packet could cause random memory corruption. 16.Fixed some potential PIC18F97J60 family Ethernet module transmit lockup conditions that occur on some networks. Previously blocking while() loops would wait indefinitely for the ECON1bit to become clear by hardware, which the hardware might never have done. 17.In MainDemo.c, a call to DelayMs() was being made using a value of 100ms. This was too long for the underlying Delay1KTCYx() C18 function and would result in a shorter than expected delay when compiled with C18. This has been fixed with a loop. Thanks go to Andy123 on the Microchip Ethernet forum for pointing this problem out. 18.Fixed a potential C18 memory overlaying problem in the TickUpdate ( see page 518)() function. Previously, the local variable used in this function might have been overlayed on other memory, resulting in random memory corruption as the ISR occurred. 19.The demo AJAX web pages in the TCPIP Demo AppWebPages folder now correctly display and self-refresh in Firefox 2. Previously, it would work in Firefox 1.5 and Microsoft Internet Explorer, but not Firefox 2. Thanks go to "gohsthb" on the Microchip Ethernet forum for identifying this correction. 20.Rewrote the GenericTCPServer.c example to not use an application RAM FIFO for buffering. Since the TCP module implements its own FIFOing, the application has limited need for its own FIFO too. This fixes a previous bug where the GenericTCPServer ( see page 98) was not checking the number of incoming bytes with the remaining size available of the App FIFO. This would have previously resulted in a buffer overflow, corrupting the RX data if too much arrived all at once. 21.Fixed a potential MPFS classic inline ASM30 assembly code problem where web pages stored in internal Flash and C30 with optimizations enabled could result in data corruption. 22.Fixed a UDPPut ( see page 528)() tracking problem that would result in extra bytes being appended to the end of a packet if the UDPSetTxBuffer ( see page 531)() function was used. This previously caused the SNMP module to send some junk data at the end of its packets. 23.Fixed a potential TCP problem where transmitted FIN packets might not get retransmitted properly if the remote node never acknowledged the data that was transmitted just before the FIN was sent. 24.Fixed a NetBIOS Name Service bug where the response packet would sometimes get sent to an incorrect address. It now consistently responds to the unicast MAC/IP address of the NBNS query packet. 25.Added padding to all transmitted DHCP messages to make the minimum UDP payload at least 300 bytes. This fixes compatibility with some older BOOTP relay devices which discard smaller packets. Thanks go to Dave Collier on the Microchip Ethernet forum for pointing this problem out. 26.Substantially shrunk the number of retransmission attempts made in the TCP_SYN_RECEIVED state. This improves recovery time when attacked by a SYN flood Denial of Service event. The recovery time is now 7 seconds (3 total packets) instead of 31 seconds (6 total packets) 27.Fixed the possibility of the NetBIOS Name Service module giving out the board's static IP address before a DHCP lease could be obtained. NBNS requests are now only serviced when originating from nodes on the same subnet. 28.Fixed storage of MPFS classic in internal program memory when using the HI-TECH PICC-18 compiler. 29.Substantially revised TCP.c, fixing many TCP bugs and possibly adding new ones. Thanks go to Michael Rubinstein for finding several of these TCP problems. 30.The DNS client module will now time out and return failure if the DNS server cannot be ARPed or does not respond to the DNS query. Each timeout is set to 1 second and 3 total ARP and 3 total DNS query attempts are possible. Previously, it would retry indefinitely, causing the calling application to deadlock. Known Problems: 1. Telnet ( see page 485) server module does not implement a lot of Telnet ( see page 485) functions. As a result, it will likely not display correctly or work at all with some Telnet ( see page 485) clients. The server was tested with the Microsoft telnet.exe utility which is provided with Microsoft Windows. 2. TFTPc module has not been tested with this version. 3. If the DHCP client and DHCP server are used at the same time and you connect ( see page 168) two similar boards to each other (ex: two PICDEM.net 2 boards connected via a crossover cable), a race condition can occur where both nodes will disable their DHCP server and neither board will get a successful DHCP lease. If this unlikely scenario occurs, as a work around, simply reset one of the boards to reenable it's DHCP server. 4. HI-TECH PICC-18 projects may not compile when targeting the external ENC28J60 chip on the PICDEM.net 2 development board (instead of the internal Ethernet controller). This problem only applies when a PIC18F97J60 family part is the target. I.e. it compiles correctly for the HPC_EXPLORER + Ethernet PICtail. 5. HI-TECH PICC-18 projects will not correctly set the processor configuration fuses through code using the __CONFIG() macro. Ensure that the configuration fuses are manually set correctly via the MPLAB IDE Configuration Bits dialog. This problem has been observed with compiler version 9.50PL3. Testing and Performance Notes: 1. Make sure to use MPLAB IDE 7.62 or higher with this version. Versions below 7.61 will not work. Version 7.62 has cool new features like C auto-word complete and function parameter tooltips that can be enabled (disabled by default). 33
Microchip TCP/IP Stack Help 2. Testing was done using MPLAB C18 version 3.12, MPLAB C30 version 3.01, and HI-TECH PICC-18 version 9.50PL3. Make sure to upgrade your tools to at least these versions.
****** v4.02 10 April 2007 ****** IMPORTANT NOTE: You must use MPLAB 7.41 or higher to successfully open the MPLAB projects. IMPORTANT NOTE2:If an external serial EEPROM memory is used to store AppConfig, it's contents will be invalidated the first time you run this version, restoring the AppConfig defaults. The AppConfig structure has been optimized. IMPORTANT NOTE3:If an external serial EEPROM memory for MPFS, you will need to recreate the MPFS image and program your EEPROM. A 32 bit addressing format is now used. Changes: 1. Implemented TCP RX packet order correction logic. The stack can now accept ( see page 166) TCP frames that arrive out-of-order without requiring the remote node to go through a retransmit cycle. This dramatically improves RX performance when communicating over the Internet. 2. UDPOpen ( see page 524)() now can handle a NULL pointer for remoteNode. In this case, the broadcast IP/MAC addresses will be used for the remoteNode (destination address of outbound packets). 3. Recreated MPLAB projects for the HI-TECH PICC-18 compiler. These were temporarily absent from 4.00RC. This project works with the PIC18F97J60 with internal Ethernet module, assuming the correct compiler version is present. 4. Moved all the headers around. Most of them are in "Microchip SolutionsMicrochipIncludeTCPIP Stack" now. This change was made to again be more compatible with other (future) Microchip software libraries. 5. New UDPPut ( see page 528)() behavior. Now, if space in the Ethernet TX buffer runs out, the packet will not automatically be transmitted. You must call UDPFlush ( see page 526)() to cause the packet to be transmitted. 6. Added UDPGetArray ( see page 527)(), UDPPutArray ( see page 529)(), UDPPutROMArray ( see page 529)(), UDPPutString ( see page 530)() and UDPPutROMString ( see page 530)() user API functions. These functions perform substantially better than calling UDPPut ( see page 528)() successively and allow greater application programming flexibility. 7. Changed TCPPutString ( see page 460)() and TCPPutROMString ( see page 459)() APIs to now return an updated string pointer instead of a count of bytes successfully placed in the TX buffer. 8. Added UDPPerformanceTest.c. By default this module causes UDP packets containing 1024 bytes of application data to be broadcasted on UDP port 12345. Use a packet sniffer, such as Wireshark (http://www.wireshark.com/) to capture and derive stack overhead/UDP TX performance characteristics with this module. Note that this test uses the UDPPutROMArray ( see page 529)() function. Applications which use successive calls to UDPPut ( see page 528)() will be slower. To enable this module, #define STACK_USE_UDP_PERFORMANCE_TEST in TCPIPConfig.h. 9. Added TCPPerformanceTest.c. By default this module listens on TCP port 12345. When a remote client connects, this server module will being transmitting the maximum possible amount of application data that it can, given your TCP TX FIFO size. Use a packet sniffer, such as Wireshark (http://www.wireshark.com/) to capture and derive stack overhead/TCP TX performance characteristics with this module. Any TCP client can be used, including readily available utilities such as the telnet.exe utility available on Microsoft Windows XP. To use it to connect ( see page 168) to the test module, run: "telnet.exe xxx.xxx.xxx.xxx 12345" where xxx.xxx.xxx.xxx is the board's IP address. Note that this test uses the TCPPutROMArray ( see page 459)() function. Applications which use successive calls to TCPPut ( see page 458)() will be slower. To enable this module, #define STACK_USE_TCP_PERFORMANCE_TEST in TCPIPConfig.h. 10.Added Reboot.c module. By default, this module listens on UDP port 30304. If the application byte 0x00 arrives on this port, the PIC will reset. This is primarily useful for remote Bootloader entry. #define STACK_USE_REBOOT_SERVER in TCPIPConfig.h to enable this module. Note that since no encrypted challenge/response algorithm is currently implemented, this module is a Denial of Service vulnerability, so it should not be enabled unless there is a specific need for it. 11.Made the TickUpdate ( see page 518)() ISR routine execute in the low priority ISR instead of the default high priority ISR. The Microchip TCP/IP stack does not need 34
Microchip TCP/IP Stack Help any interrupts except this low priority timer. 12.Renamed STACK_USE_DHCP macro to STACK_USE_DHCP_CLIENT 13.Added STACK_USE_MPFS macro. 14.Changed UDPIsPutReady ( see page 528)() to return a WORD instead of a BOOL. The WORD is the number of bytes that can be put into the buffer. 15.Changed MACGetArray() to accept ( see page 166) a NULL pointer. If NULL, the retrieved data will simply be discarded. This also changes the behavior of UDPGetArray ( see page 527)() and TCPGetArray ( see page 451)() to match, throwing bytes away if a NULL pointer is given. 16.Added a very simple DHCP Server module. This module has limitations and is useful for a single client only. Its purpose is to allow you to directly connect ( see page 168) the board to a standard PC through a crossover cable (no other network nodes attached). The server is coded to automatically disable itself if the DHCP client is also enabled and another DHCP server is detected on the network. This allows both the DHCP server and DHCP client to coexist without any manual reconfiguration. 17.Added DNSResolveROM ( see page 183)() function for resolving host names that are stored in program memory, ex: literal strings. 18.Added a TCP automatic transmit/window update timer. It defaults to TCP_AUTO_TRANSMIT_TIMEOUT_VAL ( see page 478) (40ms) after the first get or put operation following the last automatic transmit/window update. This timer enhances performance, especially when streaming data over the Internet where round trip times can be several tens to low hundreds of milliseconds. This also improves application coding flexibility as TCPFlush ( see page 450)() need not be called anymore. 19.Added TCP delayed ACKnowledgement timer. This conserves bandwidth by transmitting fewer ACKs and prevents inadvertently influencing remote slow start/collision avoidance and fast retransmit algorithms. 20.Completely rewrote ICMP (ping) server module. It is now much smaller (ROM and RAM), faster, and can handle packets of 576 bytes or larger, if no IP fragmentation occurs. 21.Rewrote StackTsk() stack manager. It is much simpler now. 22.Added TCPFind ( see page 447)(), TCPFindArray ( see page 447)(), and TCPFindROMArray ( see page 449)() user API functions. These functions peek inside a given TCP socket's RX FIFO (without removing anything) and looks for a particular byte or array of bytes. This should greatly simplify the creation of application code whenever variable length fields are used (ex: text strings terminated by rn). It supports case insensitive text searching or binary searching, as well as an offset to start searching at. 23.Added TCPGetRxFIFOFree ( see page 452)() user API. It returns the number of bytes of free space in the TCP's RX FIFO. 24.Changed default TICK resolution to 1ms (from 10ms) and improved accuracy. 25.Added outbound ping capabilities (i.e. board can now ping another board or a PC). To enable these features, define STACK_USE_ICMP_CLIENT. This will enable several new APIs, including ICMPBeginUsage ( see page 261)(), ICMPSendPing ( see page 262)(), ICMPGetReply ( see page 263)(), and ICMPEndUsage ( see page 264)(). The functions should be called in this order. See the PingDemo ( see page 99)() function in MainDemo.c for an example of how to use them. By default, pushing BUTTON3 (left-most one) will cause a ping to be sent to 4.78.194.159 (ww1.microchip.com). The response time will be displayed on the LCD (assuming your development board has an LCD). 26.Cleaned up C30 3.00 signed/unsigned warnings. 27.Removed PIC18F97J60_TEST_BOARD hardware profile support. This stack no longer supports it due to the old beta silicon (with errata) mounted on these boards. 28.Added support for ROM pointers for all of the SMTP strings (To, From, CC, Subject, etc.). If you use a ROM string, you must also set the corresponding SMTPClient.ROMPointers.xxx bit to let the SMTP module know which type of pointer was provided. See the SMTPDemo ( see page 94)() code in MainDemo.c for and example calling sequence using both ROM and RAM strings for the various fields. Fixes: 1. Fixed a critical TCP buffer corruption issue where the start of a TCB header overlapped with the last byte of the RX FIFO from the previous socket. This bug affected version 4.00RC only. 2. ETH97J60.c, TCPIP.h, and TCPIP Stack Version.txt were correctly readded to the TCPIP Demo App-C18 project using relative paths instead of absolute paths. 3. UDPOpen ( see page 524)() now dynamically assigns a local port number if you call it and give it a 0x0000 port number. This should fix some UDP applications from not working (ex: DNS Client module) with some computers/routers/networks which throw away traffic originating from the invalid port 0x0000 value. 4. Fixed a ENC28J60 bank selection error that would occur if an application called GetCLKOUT() in ENC28J60. By default, this function is not called. 5. UnencodeURL ( see page 225)() function in Helpers.c is now tested and working. see page 451)() was used. Before the problem was fixed,
6. Fixed a TCP Window Update problem when TCPGetArray ( performance could have been terrible on reception.
7. Fixed a unintended TCP connection close if the socket was idle for about a minute. Now, TCP sockets will remain open indefinitely if there is no traffic going on. 8. Serial numbers >32K are now displayed correctly on the serial port as a positive value when C18 is used and the board is placed in configuration mode (BUTTON0 is depressed on power up). 35
Microchip TCP/IP Stack Help 9. HI-TECH PICC-18 compiler would previously incorrectly initialize the AppConfig structure. 10.Previously a processor reset was possible when accessing items in the AppConfig strucutre on 16 bit MCUs (PIC24, dsPIC) due to unaligned word accesses. This was fixed by reordering the Flags byte in the APP_CONFIG structure. 11.Rewrote DHCP client state machine, fixing the previously known problem where it would not perform a new discovery if it was trying to renew a lease with an offline DHCP server. 12.Fixed a critical deadlock problem in the ETH97J60.c MAC layer driver for the PIC18F97J60 family Ethernet controller. Previously, it was possible (although rare) that the DMAST or TXRTS bits would get stuck set if too much Ethernet traffic was received within a short interval. Previously, the MACFlush() function was unnecessarily setting TXRST, which it should not do while the Ethernet interface or DMA is being used. 13.Fixed an HTTP server state machine problem where a new connection occurring too soon on a previously used socket could cause the HTTP server to no longer respond. 14.Fixed a potential memory corruption error in the HTTPGetVar() callback which would exceed the bounds of the VarString array when returning the VAR_STACK_DATE variable. 15.Fixed a TCP transmission sequence tracking problem whenever data is retransmitted and new unflushed data is also in the TX FIFO. Thanks go to Matt Watkins on the Microchip Ethernet forum for identifying this issue. Known Problems: 1. RTL8019AS MAC layer driver has not been updated for new TCP module. Users requiring RTL8019AS support should continue to use stack version 3.75. 2. I2CEEPROM.c has not been tested or completed. Continue to use I2CEEPROM.c from stack version 3.75 if this file is needed. 3. Telnet ( see page 485) server module does not implement a lot of Telnet ( see page 485) functions. As a result, it will likely not display correctly or work at all with some Telnet ( see page 485) clients. The server was tested with the Microsoft telnet.exe utility which is provided with Microsoft Windows. 4. TFTPc module has not been tested with this version. 5. The default demo web pages which use AJAX do not automatically refresh themselves when viewed in Firefox 2.0.0.1. Earlier Firefox versions (1.5ish) probably work without any problem. 6. Files may be inaccessible in your MPFS if compiled with C18 for internal flash program memory and your total MPFS content is large (around 64KB or larger). The code attempts to access the ROM memory using a near rom pointer when a far rom pointer is needed. 7. If using MPLAB 7.52 all .s files that are compiled with C30 will not have the corresponding object file get stored in the correct directory. As a result, if you are compiling with C30 and with MPFS_USE_EEPROM not defined (i.e. storing web pages in internal program memory), the project won't link (throws a undefined reference to `MPFS_Start'). As a workaround, remove the Intermediates Directory in the MPLAB project. Alternatively upgrade MPLAB to a newer version. MPLAB IDE 7.60+ may have this fixed. 8. If the DHCP client and DHCP server are used at the same time and you connect ( see page 168) two similar boards to each other (ex: two PICDEM.net 2 boards connected via a crossover cable), a race condition can occur where both nodes will disable their DHCP server and neither board will get a successful DHCP lease. If this unlikely scenario occurs, as a work around, simply reset one of the boards to renable it's DHCP server. 9. HI-TECH PICC-18 projects may not compile when MPFS_USE_EEPROM is not defined and you are trying to store web page data in internal FLASH program memory. 10.HI-TECH PICC-18 projects may not compile when targeting the external ENC28J60 chip on the PICDEM.net 2 development board (instead of the internal Ethernet controller). This problem only applies when a PIC18F97J60 family part is the target. I.e. it compiles correctly for the HPC_EXPLORER + Ethernet PICtail. Testing and Performance Notes: 1. This stack version was compiled and tested with the following tool versions: -MPLAB IDE 7.52 -Microchip C30 version 3.00 -Microchip C18 version 3.10 -HI-TECH PICC-18 version 9.50PL3 2. Using the UDPPerformanceTest.c module, the stack can transmit around 220KBytes/second (1.75Mbits/second) of UDP application data on the PIC18F97J60 with internal Ethernet @ 41.66667MHz core clock, compiled using C18 3.10 with debug optimization settings. 3. Using the UDPPerformanceTest.c module, the stack can transmit around 392KBytes/second (3.14Mbits/second) of UDP application data on the PIC24HJ256GP610 with external ENC28J60 @ 40 MIPS, compiled using C30 3.00 with debug optimization settings. 4. Using the TCPPerformanceTest.c module, the stack can transmit around 58KBytes/second (464Kbits/second) of TCP application data on the PIC18F97J60 with internal Ethernet @ 41.66667MHz core clock, compiled using C18 3.10 with debug optimization settings, over Ethernet when using a tiny 200 byte TX TCP FIFO. Note that performance can be 36
Microchip TCP/IP Stack Help improved significantly by increasing the FIFO size and performance will drop significantly if the round trip TCP acknowledgement time is increased (ex: testing over the Internet instead of Ethernet). 5. Using the TCPPerformanceTest.c module, the stack can transmit around 69KBytes/second (558Kbits/second) of TCP application data on the PIC24HJ256GP610 with external ENC28J60 @ 40 MIPS, compiled using C30 3.00 with debug optimization settings, over Ethernet when using a tiny 200 byte TX TCP FIFO. Note that performance can be improved significantly by increasing the FIFO size and performance will drop significantly if the round trip TCP acknowledgement time is increased (ex: testing over the Internet instead of Ethernet). 6. Using the TCPPerformanceTest.c module, the stack can transmit around 178KBytes/second (1.42Mbits/second) of TCP application data on the PIC24HJ256GP610 with external ENC28J60 @ 40 MIPS, compiled using C30 3.00 with debug optimization settings, over Ethernet when using a larger 2000 byte TX TCP FIFO. Note that performance will drop significantly if the round trip TCP acknowledgement time is increased (ex: testing over the Internet instead of Ethernet).
****** v4.00RC 28 December 2006 ****** IMPORTANT NOTE: If an external serial EEPROM memory is used to store AppConfig, it's contents will be invalidated the first time you run this version, restoring the AppConfig defaults. The AppConfig structure has been optimized. IMPORTANT NOTE2: If an external serial EEPROM memory for MPFS, you will need to recreate the MPFS image and program your EEPROM. A 32 bit addressing format is now used. Changes: 1. Added Simple Mail Transfer Protocol (SMTP) client module and updated MainDemo.c to exercise the Email transmission functionality when a user pushes BUTTON0. 2. Added beta Telnet ( see page 485) server module. See Known Problems section.
3. Completely revamped the TCP module. A real transmit FIFO and receive FIFO are allocated for each TCP socket now. This greatly enhances RFC compliance, communications robustness, and makes application development easier. New APIs were added for putting and getting arrays and strings (including ROM variants). Several TCP related bugs are now fixed as a result. Please report any bugs found in the new implementation. 4. Added TCPPutArray ( see page 458)() API. see page 459)() API.
9. Changed TCPIsPutReady ( see page 454)() API. Instead of returning a BOOL, it now returns a WORD. The WORD is a count of the number of bytes that TCPPut ( see page 458)(), TCPPutArray ( see page 458)(), etc. can immediately place in the output buffer. MAKE SURE THAT YOUR CODE DOES NOT COMPARE THE RETURN RESULT OF TCPIsPutReady ( see page 454)() DIRECTLY TO TRUE. For example, "if(TCPIsPutReady ( see page 454)(MySocket ( see page 309)) == TRUE){...}" must be converted over to: "if(TCPIsPutReady ( see page 454)(MySocket ( see page 309))){...}". 10.Changed TCPIsGetReady ( see page 454)() API. Instead of returning a BOOL, it now returns a WORD. The WORD is a count of the number of bytes that TCPGet ( see page 450)() or TCPGetArray ( see page 451)() can immediately obtain. MAKE SURE THAT YOUR CODE DOES NOT COMPARE THE RETURN RESULT OF TCPIsGetReady ( see page 454)() DIRECTLY TO TRUE. For example, "if(TCPIsGetReady ( see page 454)(MySocket ( see page 309)) == TRUE){...}" must be converted over to: "if(TCPIsGetReady ( see page 454)(MySocket ( see page 309))){...}". 11.Changed TCPDiscard ( see page 446)() return type from BOOL to void. 12.Removed TCP_NO_WAIT_FOR_ACK option. It was defaulted to disabled in the last two releases of the stack and is not needed with the new TCP module. 13.Updated DNS module to include two new required APIs: DNSBeginUsage ( see page 182)() and DNSEndUsage ( see page 182)(). These functions control a one bit ownership semaphore to allow multiple applications to use the DNS module in series. If invoked correctly, this will prevent unintended bugs resulting from two applications trying to use the DNS module at the same time. Old applications, such as those based around the GenericTCPClient.c example must be updated to use these functions. 14.Started using a new project structure and folders. You must use MPLAB 7.41 or higher (stack is tested on MPLAB 7.50)
37
Microchip TCP/IP Stack Help to use the default workspaces/projects, which include files using relative paths. This should improve compatibility with some future code libraries released by Microchip. StackTsk.h was broken into TCPIPConfig.h, HardwareProfile.h, and StackTsk.h. TCPIPConfig.h now includes all stack configuration options and HardwareProfile.h contains all hardware options. No macros need be globally defined in MPLAB project now. TCPIP.h is the only header applications must include now, for any/all modules used. 15.Combined ARP.c/ARP.h and ARPTsk.c/ARPTsk.h into a single file pair: ARP.c/ARP.h. Applications built using a prior stack revision must remove all instances including "ARPTsk.h" and replace it with "ARP.h" instead. The ARP module is now simpler, more linear (easier to read), and being in one source file, allows the C compiler to optimize better. 16.Added PIC18F67J60_TEST_BOARD hardware profile to HardwareProfiles.h. This hardware profile is designed for 05-60091 (Rev 1), a development board that is not in production at this time. 17.Added DSPICDEMNET1 and DSPICDEMNET2 hardware profiles to HardwareProfiles.h for eventual support of the Microchip dsPICDEM.net 1 and dsPICDEM.net 2 demo boards. These two boards use the RTL8019AS Ethernet controller and a 24LC515 EEPROM. These changes are currently incomplete and these profiles cannot be used. 18.Began rewriting I2CEEPROM.c to support 16 bit CPUs, including the dsPIC30F6014 used on the dsPICDEM.net 1 and 2 demo boards. Note that work here is incomplete and cannot be used as a result -- see Known Problems section. 19.Partially updated RTL8019AS.c to support 16 bit CPUs, including the dsPIC30F6014 used on the dsPICDEM.net 1 and 2 demo board. Note that work here is incomplete and cannot be used as a result -- see Known Problems section. 20.Updated SNMP.c to use new typedefs in GenericTypedefs.h. Also SNMP was tested in this version. SNMP.mib was updated some to better reflect current hardware. 21.Added AN870 SNMP callbacks to MainDemo.c (a feature that was missing in 3.xx releases). This code will get compiled when STACK_USE_SNMP_SERVER is defined in TCPIPConfig.h. 22.Removed all instances of MPFS_USE_PGRM for storing in internal FLASH program memory. Storage in internal program memory is now the default. Define MPFS_USE_EEPROM to override the default and store MPFS in an external EEPROM memory. 23.Decreased program memory needed for Announce.c module by about 180 bytes. Multiple inline calls to UDPPut ( see page 528)() were removed. 24.UDP checksum checking logic has been improved. The UDP layer now avoids writing the pseudo header checksum in the RX buffer. 25.Swapped endianess of the returned checksum from CalcIPBufferChecksum ( see page 213)(). Rewrote CalcIPBufferChecksum ( see page 213)() in Helpers.c. This improves consistency. 26.Improved swapl() in Helpers.c. 27.Improved USART baud rate (SPBRG) calculation for PIC18s. Rounding is now done to chose the most optimal value and the code will automatically select high baud rate mode (BRGH=1) if possible. Additional improvements can be made if using a newer PIC18 with the 16 bit baud rate generator. 28.Added GenericTCPServer.c example file to complement GenericTCPClient.c. The server is enabled by defining STACK_USE_GENERIC_TCP_SERVER_EXAMPLE in TCPIPConfig.h. 29.Renamed STACK_USE_GENERIC_TCP_EXAMPLE definition to STACK_USE_GENERIC_TCP_CLIENT_EXAMPLE for consistency with new server example. 30.Defaulted MPFS.exe to generate binary MPFS images using 32 bit addressing. MPFS.h has been modified to also default to use 32 bit addressing of external EEPROM images. You must rebuild any old MPFS images and reprogram them if upgrading from a previous TCP/IP stack revision, which defaulted to use 16 bit addressing. 31.Updated MPFS.exe to #include "TCPIP.h" instead of "..HeadersCompiler.h" in C files generated by the utility. 32.Added MPFSv2.exe PC utility for generating large MPFS images in program memory (ASM30 code) for C30 users. Previously, the C30 compiler placed a limit of less than 32KB of total MPFS size due to the PSV window size limitation on PIC24/dsPIC devices. To get around the limitation, use the new MPFSv2.exe utility to generate an .s file which can be included in your project instead of the .c file generated by the traditional MPFS.exe utility. Fixes: 1. Fixed a bug in ARPProcess ( see page 159)() which would incorrectly send an ARP response to an incorrect MAC & IP address if a TX buffer wasn't immediately available. 2. Fixed a TCP bug where TCPIsGetReady ( see page 454)() would return TRUE even if no data was left in the recieved packet. Previously you had to call TCPGet ( see page 450)() one last time and have it fail before TCPIsGetReady ( see page 454)() would return FALSE. 3. Modified TCP state machine. Established connections will no longer automatically close if left idle for approximately 45 seconds. Note that your application needs to ensure that no sockets unintentionally get lost (For example: a server socket that received data only is established and the cable breaks while connected. In this case, the socket would never be detected as being disconnected since the server never attempts to transmit anything). 4. Stopped overclocking dsPIC33 and PIC24H devices. Previously PLLFBD was incorrectly set to 39 instead of 38 to yield a resulting Fosc of 84MHz (42MIPS) instead of 80MHz (40MIPS) with the default Explorer 16 development board. Thanks go to Matt Watkins on the Microchip Ethernet Forum for pointing this error out. 5. Corrected a bug in IP.c where IPHeaderLen would not be properly initialized if a NON_MCHP_MAC was used (ex: RTL8019AS) and IPSetRxBuffer() was called. This bug did not affect ENC28J60 or PIC18F97J60 family support. Thanks 38
6. Updated checksum checking code in ENC28J60.c for latest silicon DMA checksum errata. 7. Declared TickCount in Tick.c/Tick.h as volatile and implemented an interrupt safe reading procedure in TickGet ( see page 516)(). Since this multibyte variable is modified in the ISR and read in the mainline code, these changes are needed to prevent rare inconsistency bugs. 8. Fixed Announce.c so the unicast remoteNode of the requesting packet would be used rather than the remoteNode of the last received packet, which may not be correct when transmitting. Thanks go to Brett Caulton for identifying this issue. 9. Fixed a DHCP bug which would cause DHCP renewals to continually occur after only 60 seconds once the original lease expired. Thanks go to Brett Caulton for identifying this issue and fix. 10.Fixed a potential TCP socket leak in the FTP module. Previously FTPDataSocket would not be reliably initialized nor closed if the connection was killed forcefully (user killed application, cable disconnected while transferring, etc.). Known Problems: 1. RTL8019AS MAC layer driver has not been updated for new TCP module. Users requiring RTL8019AS support should continue to use stack version 3.75. 2. I2CEEPROM.c has not been tested or completed. Continue to use I2CEEPROM.c from stack version 3.75 if this file is needed. 3. Telnet ( see page 485) server module is still in development. No user authentication features are currently implemented. Some telnet clients may render the telnet server output incorrectly (in the wrong locations or wrong colors). Testing has only been done with the Microsoft Windows telnet.exe utility that comes Windows XP. 4. DHCP will continually send out DHCP Request packets when the lease expires and the original DHCP server that gave the lease is offline. The board will continue to use the expired IP address until the DHCP server comes back online, at which point the lease will be renewed or a new discovery will occur. A new discovery should occur after timing out, instead. It is believed that this problem has always existed in previous stack revisions. 5. DHCP will continually send out DHCP Request packets when the lease expires and the original DHCP server that gave the lease does not include Option 54, the Server Identifier. A new discovery should occur after timing out. It is believed that this problem has always existed in previous stack revisions. 6. TFTPc module has not been tested with this version. 7. Serial numbers >32K will be displayed on the serial port as a negative value when C18 is used and the board is placed in configuration mode (RB0 button is depressed on power up).
****** v3.75 14 August 2006 ****** Changes: 1. Added beta DNS client module (DNS.c). DHCP was also updated to obtain a DNS server address. Added AppConfig.PrimaryDNSServer IP address. Added STACK_USE_DNS configuration macro. To use the DNS client, call DNSResolve ( see page 183)() with the server name, ex: DNSResolve ( see page 183)("www.microchip.com"), and then periodically call DNSIsResolved ( see page 184)() until it returns TRUE, ex: DNSIsResolved ( see page 184)(&IPAddressDestination). Only one DNS resolution can be in progress at a time. Because the DNS client is a beta module, the API or code may change before being finalized. No formal DNS API documentation is available yet. 2. Added beta NetBIOS Name Service responder module (NBNS.c). Added AppConfig.NetBIOSName string. Added STACK_USE_NBNS configuration macro. Added MY_DEFAULT_HOST_NAME macro in StackTsk.h. Now, whenever a NetBIOS broadcast attempting to resolve AppConfig.NetBIOSName arrives, a response will be made. This form of name resolution only works on a single subnet. Off the subnet, manual registration in a DNS server or other means will be needed to allow the local Host Name to be recognized and translated to an IP address. The default NetBIOS name for the board is "MCHPBOARD". To test the NetBIOS Name Service module, try entering http://MCHPBOARD/ into your web browser instead of the board's IP address. 3. Added beta HTTP client module (GenericTCPClient.c). This module demonstrates how to make a TCP client application. To test this module, uncomment the STACK_USE_GENERIC_TCP_EXAMPLE macro in StackTsk.h, recompile, and then press the BUTTON1 button while the stack is running. RemoteURL ( see page 96)[] should be downloaded from 39
Microchip TCP/IP Stack Help ServerName ( see page 96)[] and written to the UART. For the default values of ServerName ( see page 96)[] and RemoteURL ( see page 96)[], the HTML search page for "Microchip" will be fetched from "www.google.com" and written to the serial port. No formal documentation is available for this example yet. 4. Added Embedded Ethernet Device Discoverer PC project to aid in embedded product discovery when connected to a network and demonstrate how to write PC applications which can communicate with embedded devices. The source code for this device is included. It can be built using the Microsoft Visual C# 2005 Express Edition compiler. At the time of stack release, this 3rd party PC development tool can be downloaded at no cost from http://msdn.microsoft.com/vstudio/express/. If using only the Microchip Device Discoverer executable file without the Visual C# compiler, the .NET Framework 2.0 must be installed on the local PC. The application setup utility should allow dynamic downloading of this component if the target machine does not already have it installed. 5. Updated Announce.c to listen ( see page 172) and respond to discovery requests sent to UDP port 30303 starting with the character 'D'. To test this functionality, use the Embedded Ethernet Device Discoverer on a PC connected to the same subnet. 6. Updated UART configuration menu to accommodate the new beta module configuration options (DNS server address, device host name). 7. Increased MPFS reserve block to 64 bytes from 32. Also, because the APP_CONFIG structure was updated, all current MPFS images and data stored in deployed EEPROMs needs to be updated. 8. Added a means to erase (invalidate) the onboard EEPROM using the BUTTON0 momentary switch (right-most switch on demo boards with multiple switches). To erase the EEPROM, hold down BUTTON0, RESET the board (press and release MCLR switch), and then continue to hold down BUTTON0 for an additional 4 seconds. If you press MCLR again, the EEPROM contents will now be invalid. If you press '0' on the UART, the same configuration that was read prior to invalidating the contents will be written back into the EEPROM. Invalidating the EEPROM allows the MY_DEFAULT_* constants to get loaded into a previously programmed EEPROM chip. Because of change #7, this procedure should be done for all currently programmed EEPROMs to prevent anomalous values from being read. 9. remoteNode in StackTsk.c was changed from private to global scope. Now external modules can reference the address of the last received packet. Announce.c uses this to send a unicast response to a broadcast discovery request. 10.All stack modules that can be disabled (DHCP.c, FTP.c, etc) now will no longer emit a compiler error if you have it in the project without defining the appropriate macro (STACK_USE_DHCP, STACK_USE_FTP, etc). It will simply generate no machine code when compiled and the stack will not use that module. Make sure the proper macro is defined for each module that you wish to use. 11.Added SetRXHashTableEntry() to ENC28J60.c. This function can be used to set the appropriate bit in the Hash Table registers to join a particular multicast group. 12.Added Realtek RTL8019AS Ethernet controller support to the stack. MAC.c was renamed to RTL8019AS.c. This Ethernet controller is not recommended for new designs. RTL8019AS support was reintroduced to provide ongoing assistance to former Application designs implementing this chip. For new applications, use the Microchip ENC28J60 or PIC18F97J60 family of microcontrollers. 13.Added I2C EEPROM support for MPFS storage. In older 2.xx stack revisions, I2C EEPROM was supported by the XEEPROM.c file. This file has been renamed to I2CEEPROM.c. It is mutually exclusive with SPIEEPROM.c, and only one may be included in the project at a time. 14.Added new hardware definitions to Compiler.h. Pin mappings for the PICDEMNET and PIC18F97J60_TEST_BOARD boards have been added. FS_USB was also defined; however, it is untested and not recommended. See Compiler.h. The PIC18F97J60_TEST_BOARD is a non-production board that some Early Adopters of the PIC18F97J60 family parts have. 15.Changed type definitions for BYTE_VAL, WORD_VAL, DWORD_VAL, and moved the generic typedefs to GenericTypeDefs.h from StackTsk.h. This should improve compatibility with some future code libraries released by Microchip. 16.LCDBlocking.c module was modified to support 4-bit interfaces to LCD modules. The PICDEM.net board has the module wired using a 4-bit bus. Fixes: 1. Fixed a serious MAC TXBuffer leak in TCP.c. Previously TCP.c would allocate a buffer for each socket in use, but under heavy traffic conditions (ex: user holds down F5 on web browser), the buffer handle might have been discarded before releasing the buffer. As a result all TCP connections would have lost the ability to send any application data after the TXBuffer pool ran out. 2. In the TCP_SYN_SENT TCP state, ACKs may only be received (as opposed to SYN+ACK packets) if the remote node thinks the connection is already open. A RST is now sent in response to an unexpected ACK, which may improve reconnection time when this (rare) condition occurs. 3. A bug was present in the UDP module where remote MAC addresses would be cached for each socket, even when UDPInit ( see page 534)() or UDPClose ( see page 525)() was called, or the microcontroller was reset. As a result, responses to incoming packets could have been sent to the wrong MAC address. UDP Sockets ( see page 149) are now properly initialized/closed.
40
Microchip TCP/IP Stack Help 4. Fixed a potential timing bug in LCDBlocking.c. For lower values of CLOCK_FREQ, insufficient delay time was given to the LCD module, potentially causing improper operation. 5. Changed PIC24F to default to the XT oscillator fuse rather than HS. The PIC24FJ128GA010 data sheet, rev. C reports that 8MHz should be used with XT mode, not HS mode like prior data sheets. 6. Added a couple of wait states to the Realtek RTL8019AS MAC layer module for NICPut() and NICGet(). Previously, the PICmicro could not operate above approximately 25MHz without losing communication with the RTL8019AS chip. 7. Updated PC based MPFS utility. When generating C files to be added to your MPLAB project, the include path to "Compiler.h" is now "..IncludeCompiler.h". The output file, ex: "MPFSImg.c" should be placed in the "Source" subfolder before compiling. For example, if you are in the main stack folder with the MPLAB projects, type: "mpfs /c WebPages SourceMPFSImg.c" 8. IP Gleaning will now get properly disabled when, through the RS232 configuration application, DHCP and IP Gleaning are disabled. The stack will still respond to ping requests which have the wrong destination IP address, but a correct MAC address. However, the stack will continue to keep its statically defined IP address when DHCP/IP Gleaning are disabled and the ping arrives. 9. SPIEEPROM.c now saves and reconfigures the EEPROM_SPICON1 register (SSPCON1) before reading or writing to the SPI. After the read/write, it restores the saved state. This allows the SPI bus to operate at different speeds, depending on what peripheral is being accessed if other devices share the bus and can support different speeds. In particular, this fixes the SPI @ 10.4MHz problem on the PICDEM.net 2 board when using the ENC28J60. Known Problems: 1. DHCP will continually send out DHCP Request packets when the lease expires and the original DHCP server that gave the lease is offline. The board will continue to use the expired IP address until the DHCP server comes back online, at which point the lease will be renewed or a new discovery will occur. A new discovery should occur after timing out, instead. It is believed that this problem has always existed in previous stack revisions. 2. DHCP will continually send out DHCP Request packets when the lease expires and the original DHCP server that gave the lease does not include Option 54, the Server Identifier. A new discovery should occur after timing out. It is believed that this problem has always existed in previous stack revisions. 3. When an MPFS .c image file is added to a C30 project, a linking error reporting insufficient contiguous .const memory may occur when too much data is in the MPFS image (PSV window size limitation). Using the PSV window, 1 out of every 3 program memory bytes is wasted. 4. MACSetPMFilter(), MACDisablePMFilter(), and MACCopyRxToTx() have not been tested and possibly do not work. 5. SNMP, TFTPc modules have not been tested with this version. 6. Serial numbers >32K will be displayed on the serial port as a negative value when C18 is used and the board is placed in configuration mode (RB0 button is depressed on power up). 7. The C30 linker may misplace the __CONFIG2 section or disallow usage of MPFS images that are too big (add too much to the .const code section). The consequences of this are that the first configuration word at 0x157FC may not get set through code (must use the Configuration Bits dialog instead), and/or the project will not compile. This problem has been observed with C30 ver. 2.02 on the PIC24FJ128GA010 product. To work around this problem, the p24FJ128GA010.gld linker script has been modified. Specifically, line 68 has been commented out, which causes the linker to place all .text sections after placing all absolute sections. SSR 25966 in the C30 2.02 release notes may be related. 8. It is observed with the Realtek RTL8019AS Ethernet controller and the demo AJAX web page which self refreshes rapidly, that occasional HTTP GET requests sent by the computer do not get received by the HTTP server. This is believed to be a RTL8019AS MAC layer bug. The TCP protocol handles the packet loss, but application performance suffers while waiting for the TCP retransmission. This problem is not observed with ENC28J60.c or ETH97J60.c MAC layers. 9. The HI-TECH compiler version 9.50PL1 crashes when compiling LCDBlocking.c with 4 bit mode (PICDEMNET) and using a warning level of -3 or higher. To work around the problem, the HI TECH projects were set to use warning level -4. Guiding Notes: 1. To use the stack on a classic PICDEM.net demo board with the Realtek Ethernet controller, a PIC18F452 processor, and Microchip C18: -Use the C18EEPROM MPLAB project -Change the processor in the MPLAB IDE -Change linker script to "18f452i.lkr" in the MPLAB project. Use the one provided in the Linker subfolder, it has been modified to make more RAM available. -Update the hardware definitions macro. Click on Project -> Build Options... -> Project -> MPLAB C18 -> Add PICDEMNET, remove HPC_EXPLORER) -Remove ENC28J60.c from the project -Remove SPIEEPROM.c from the project -Add RTL8019AS.c to the project -Add I2CEEPROM.c to the project -Enable all compiler optimizations (Project -> Build Options... -> Project -> MPLAB C18 -> Categories Optimization -> Enable all)
41
****** v3.60 12 July 2006 ****** General Information: This stack version is being publicly released, so the following changes are with respect to the prior public stack release (v3.02). Interim stack changes for version 3.16 and 3.50 are documented below for those using non-public releases, but can be ignored by most people. Troubleshooting notes: 1. If you have an Ethernet PICtail revision 2.1 and are having reliability issues when viewing the fast-refresh demo web page, you may need to install resistors in series with the ENC28J60 SI, nCS, and SCK pins. The recommended value is 100 to 200 ohms. This will reduce signal undershoot caused by long traces (parasitic inductance), which can violate the absolute maximum electrical specs and cause SPI data corruption. The HPC Explorer Rev 5 has fairly long traces to the PICtail connector. 2. Enabling C30 2.02 compiler optimizations on the dsPIC33FJ256GP710, PIC24HJ256GP610 ES chips may produce unreliable code. 3. When changing a C30 project to a PIC24H or dsPIC33F processor on the Explorer 16 demo board, the JTAG configuration fuse should be disabled to free the I/O pins associated with it. JTAG is enabled by default. 4. This stack release was tested using MPLAB 7.40, C18 version 3.03, C30 version 2.02, and HI TECH PICC18 version 9.50PL1. 5. When using the Ethernet PICtail board and HPC Explorer demo boards, make sure to plug the power into the Ethernet PICtail and not the HPC Explorer. The HPC Explorer's power regulator cannot provide enough current. Changes: 1. Source files have been split into separate directories. To compile old applications with this new stack, application source files may need to be updated to include the proper path to the stack header files. 2. New MPLAB projects have been created: -C18EEPROM: Equivalent to the previously named "mpnicee" project. Designed for PIC18's using the C18 compiler. Web page content, board's IP address, MAC address, DHCP enabled state, etc. is stored in an external SPI EEPROM (25LC256 on demo boards). FTP Server demo is included. -C30EEPROM: New supporting PIC24 and dsPIC controllers using the C30 compiler. Similar to C18EEPROM. -C18ProgramMem: Equivalent to the previously named "mpnicpg" project. Web page content stored in internal FLASH program memory. Board's IP address, MAC address, DHCP enabled state, etc. is stored only in RAM and defaults are loaded from MY_DEFAULT_* constants in StackTsk.h. FTP Server demo is not included. Web pages cannot be updated remotely. -C30ProgramMem: New supporting PIC24 and dsPIC controllers using the C30 compiler. Similar to C18ProgramMem. -HTC18EEPROM: Equivalent to the previously named "htnicee" project. Designed for PIC18's using the HI TECH PICC18 compiler. Similar to C18EEPROM. -HTC18ProgramMem: Equivalent to the previously named "htnicpg" project. Designed for PIC18's using the HI TECH PICC18 compiler. Similar to C18ProgramMem. 3. Created hardware definitions (pins, interrupt flags, special registers, etc) in Compiler.h for easy changing of hardware. Four demo board combinations are supported out-of-box now: -EXPLORER_16: Explorer 16 motherboard + Ethernet PICtail Plus daughter card. Tested with dsPIC33FJ256GP710, PIC24HJ256GP610, and PIC24F128GA010 ES PIMs. -HPC_EXPLORER: PICDEM HPC Explorer motherboard + Ethernet PICtail daughter card. Tested with PIC18F8722 onboard and PIC18F87J10 PIM. -DSPICDEM11: dsPICDEM 1.1 motherboard + Ethernet PICtail daughter card (manually air wired). See Compiler.h for proper pins to air wire. Tested with dsPIC30F6014A PIM. -PICDEMNET2: PICDEM.net 2 motherboard (PIC18F97J60) Change boards by changing the defined macro (Project -> Build Options... -> Project -> MPLAB Cxx -> Add macro). When moving to custom hardware, add an appropriate profile to Compiler.h. YOUR_BOARD is present as a placeholder. 4. Added Ethernet PICtail Plus schematic (reference ENC28J60 daughter card design for Explorer 16 demo board). These boards have a Microchip part number of AC164123. 5. Latest ENC28J60 rev. B5 errata workarounds added. The code checks the EREVID register and implements the appropriate workarounds as needed for the silicon revision, so rev. B1, B4, and B5 are all supported in this stack release. 6. Significantly revised demonstration web page content in WebPages folder to use AJAX technology. Using asynchronous JavaScript code executing in the web browser, the status sections of the page are updated rapidly from the web server without doing a full page refresh. As a result, a virtually real time update of the potentiometer and button values can be displayed. Due to the constant use of new TCP sockets, multiple simultaneous users are not recommended. See the Index.cgi file for a simple static method of retrieving dynamic variables from the HTTP server. 42
Microchip TCP/IP Stack Help 7. Changed IP Gleaning procedure. Now, if DHCP is enabled, the DHCP module will continue to look for a new IP address/renew existing IP address if the IP address is configured using IP Gleaning. Previously, the DHCP module would be disabled once a successful ICMP packet was received and used to configure the IP address. 8. MAX_RETRY_COUNTS is 3 (previously it was 3, but an interim release changed it to 5). 9. Updated TCP state machine. It now includes the TCP_FIN_WAIT_2 state. Some other changes were made to handle errors more robustly. 10.AN0String and AN1String now return all characters excluding the null terminator when the HTTP server calls HTTPGetVar (except when the string is 0 length). Previously, the null terminator was returned as well. 11.Dynamic pages (ie: .cgi files) are now served with an expired HTTP header to prevent browser caching and allow more dynamic content to be displayed. 12.Support for the HI TECH PICC18 compiler has changed. Special Function Register bits and other definitions have changed substantially from the previous HI TECH PICC18 projects in TCP/IP stack version 3.02 and earlier. The C18/C30 SFR and SFRbits naming conventions are now used and special remapping macros in Compiler.h are used to maintain a consistent syntax. The HI TECH PICC18 projects were tested with compiler version 9.50PL1 on the HPC Explorer board (PIC18F8722). 13.FTP client hash printing has been added to the FTP server. Now, whenever a chunk of data is successfully uploaded to the device, a '#' character will appear on the FTP client screen. The numbers of bytes each '#' represents is variable. 14.To improve maintainability, built in support for the "Compatible" A/D converter present on older PIC18 parts (ex: PIC18F452) has been removed. 15.Removed old LCD code originally provided for the PICDEM.net demo board. 16.Added LCDBlocking.c and LCDBlocking.h, which implement simple routines for writing to the LCD module on the Explorer 16 and PICDEM.net 2 development boards. The LCD on the dsPICDEM 1.1 board is not supported. The stack version and IP address are shown on the LCD on power up. 17.UART functions in MainDemo.c were replaced with C18 and C30 peripheral library functions. However, because the UART peripheral libraries are not being updated for newer silicon devices, the code was copied into UART.c and is compiled with the stack. 18.Multiple TX buffer support has been implemented. Most stack layers have been touched. ENC28J60.c has the most extensive changes. Each socket may use only one TX buffer. 19.Implemented TCP retransmission support regardless of if TCP_NO_WAIT_FOR_ACK is defined or not. 20.TCP_NO_WAIT_FOR_ACK in StackTsk.h has been undefined by default. This should increase default TCP connection robustness. Packets sent from the stack to the remote node will now be detected and retransmitted if lost or corrupted. 21.All TCP packets are now retransmitted immediately after being initially transmitted when TCP_NO_WAIT_FOR_ACK is undefined. This improves throughput greatly when communicating with systems which wait a long time before transmitting ACKs. TCP/IP stacks, such as that used by Microsoft Windows, implement the TCP Delayed Acknowledgement algorithm, which is why this retransmission is necessary for high performance. The double transmission feature can be disabled in the Microchip TCP/IP stack by defining "DEBUG" either in the TCP.c file or the project compiler macros section. Using DEBUG mode can be useful when trying to look for errors using Ethreal [ http://www.ethereal/ ]. 22.Lowered TCP_START_TIMEOUT_VAL ( see page 483) from 60 seconds to 3 seconds. 60 seconds is an unreasonably long timeout for modern day network speeds. 23.Native support for the SLIP module has been dropped.
Fixes: 1. A new IP address obtained via IP Gleaning will now update the LCD (if present), invoke the Announce ( module (for MCHPDetect.exe), and output the new address out the RS232 port. see page 152)
2. DHCP client will now correctly use the first DHCP offer received when connected to a network running multiple DHCP servers. Previously, the board would get no IP address when attached to a network with multiple DHCP servers (unless the DHCP request was transmitted before a second DHCP offer was received -- a relatively rare event). Additionally, DHCPLeaseTime does not get reset to 60 seconds or the value stored in the last DHCP packet received prior to receiving the ACK. 3. UDPProces() will now correctly process received UDP packets that have a 0x0000 checksum field. The UDP protocol specifies that 0x0000 means the checksum is disabled. Packets with a 0x0000 checksum were previously thrown away unless the calculated checksum also happened to be 0x0000. 4. The TCPIsPutReady ( see page 454)() function will now honor the remote node's TCP window size. In other words, if the remote application pauses or cannot handle the incoming data rate, the TCP flow control feature will correctly function. Previously, if the remote node ran out of incoming buffer memory, the TCP layer would still allow more data to be transmitted. This would result in the loss or corruption of application data, with a potentially broken connection. The change requires 2 more bytes of RAM per TCP socket (TCB array). Known Problems: 1. On PICDEM.net 2 board ENC28J60 and 25LC256 EEPROM share the same SPI1 module. At 3.3V, the 25LC256 is only 43
Microchip TCP/IP Stack Help rated to 5MHz SPI clock, but the code is setting it to 10.4MHz because the MACInit() function reconfigures the same SPI1 module. 2. DHCP will continually send out DHCP Request packets when the lease expires and the original DHCP server that gave the lease is offline. The board will continue to use the expired IP address until the DHCP server comes back online, at which point the lease will be renewed or a new discovery will occur. A new discovery should occur after timing out, instead. It is believe that this problem has always existed in previous stack revisions. 3. DHCP will continually send out DHCP Request packets when the lease expires and the original DHCP server that gave the lease does not include Option 54, the Server Identifier. A new discovery should occur after timing out. It is believe that this problem has always existed in previous stack revisions. 4. The MPFS utility has not been updated. When creating a .c image file, the include path for the Compiler.h file will be incorrect and need to be manually updated to "..IncludeCompiler.h". 5. When an MPFS .c image file is added to a C30 project, a linking error reporting insufficient contiguous .const memory may occur when too much data is in the MPFS image (PSV window size limitation). Using the PSV window, 1 out of every 3 program memory bytes is wasted. 6. MACSetPMFilter(), MACDisablePMFilter(), and MACCopyRxToTx() have not been tested and possibly do not work. 7. SNMP, TFTPc modules have not been tested with this version. 8. Serial numbers >32K will be displayed on the serial port as a negative value when C18 is used and the board is placed in configuration mode (RB0 button is depressed on power up). 9. IP Gleaning may not get disabled when, through the RS232 configuration application, DHCP and IP Gleaning are disabled. 10.The C30 linker may misplace the __CONFIG2 section or disallow usage of MPFS images that are too big (add too much to the .const code section). The consequences of this are that the first configuration word at 0x157FC may not get set through code (must use the Configuration Bits dialog instead), and/or the project will not compile. This problem has been observed with C30 ver. 2.02 on the PIC24FJ128GA010 product. To work around this problem, the p24FJ128GA010.gld linker script has been modified. Specifically, line 68 has been commented out, which causes the linker to place all .text sections after placing all absolute sections. SSR 25966 in the C30 2.02 release notes may be related. Guiding Notes: 1. To change processors using a C18* project: -Change the processor in the MPLAB IDE -Change linker script (ex: 18f87j10i.lkr) in the MPLAB project. Use *i.lkr if the ICD2 is going to be used to debug with. -Update the hardware definitions in Compiler.h or change your demo board selection macro. (Project -> Build Options... -> Project -> MPLAB Cxx -> PICDEMNET2, etc) 2. To change processors using a HTC18* project: -Change the processor in the MPLAB IDE -Update the hardware definitions in Compiler.h or change your demo board selection macro. (Project -> Build Options... -> Project -> MPLAB Cxx -> PICDEMNET2, etc) 3. To change processors using a C30* project: -Change the processor in the MPLAB IDE -Change linker script (ex: p33FJ256GP710.gld) in the MPLAB project. -Update the hardware definitions in Compiler.h or change your demo board selection macro. (Project -> Build Options... -> Project -> MPLAB Cxx -> DSPICDEM11, etc) -Disable JTAG configuration fuse, if enabled 4. When using the PICDEM.net 2 board, to write code targeting the PIC18F97J60 family Ethernet module: -Remove ENC28J60.c from the project -Add ETH97J60.c to the project -Plug the Ethernet cable into the left-most RJ45 jack (next to LCD) 5. When using the PICDEM.net 2 board, to write code targeting the ENC28J60 Ethernet device: -Make sure ENC28J60.c is in the project -Make sure that ETH97J60.c is not in the project -Plug the Ethernet cable into the right-most RJ45 jack (next to board edge) 6. When using the PICDEM.net 2 board, to write code targeting an Ethernet PICtail module (ENC28J60): -Make sure ENC28J60.c is in the project -Make sure that ETH97J60.c is not in the project -Make sure that the Ethernet PICtail J9 jumper is in the 2-3 position (default). -Properly update the hardware profile in Compiler.h. ENC_CS_TRIS and ENC_CS_IO need to be changed from D3 to B3. -Plug the Ethernet cable into the PICtail -Plug power into the PICDEM.net 2 board 7. When using the Explorer 16 and Ethernet PICtail Plus demo boards, make sure to mate the PICtail to the motherboard using the topmost socket position, leaving the cable hanging over prototyping area. If SPI2 is desired, the PICtail should have the same orientation but be installed in the middle slot. Using SPI2, the hardware profile will need to be updated in Compiler.h.
44
****** v3.50 13 April 2006 ****** Changes: 1. Improved dsPIC33F and PIC24H support. UART functions are included now instead of precompiled object files for the PIC24F. The 12-bit A/D converter is now shown in use on the demo web content. When changing a C30 project to a PIC24H or dsPIC33F processor on the Explorer 16 demo board, the JTAG configuration fuse should be disabled to free the I/O pins associated with it. JTAG is enabled by default. 2. Added LCDBlocking.c and LCDBlocking.h, which implement simple routines for writing to the LCD module on the Explorer 16 development board. The stack version and IP address are shown on the LCD on power up. 3. Added "C18ProgramMem" and "C30ProgramMem" MPLAB projects for MPFS storage (web page content) on on-chip program memory. These projects are equivalent to the previously named "mpnicpg" project in prior stack releases. 4. Multiple TX buffer support has been implemented. Most stack layers have been touched. ENC28J60.c has the most extensive changes. Each socket may use only one TX buffer. 5. Implemented TCP retransmission support when TCP_NO_WAIT_FOR_ACK is undefined. 6. TCP_NO_WAIT_FOR_ACK in StackTsk.h has been undefined by default. This should increase default TCP connection robustness. 7. All TCP packets are now retransmitted immediately after being initially transmitted when TCP_NO_WAIT_FOR_ACK is undefined. This improves throughput greatly when communicating with systems which wait a long time before transmitting ACKs. 8. Lowered TCP_START_TIMEOUT_VAL ( see page 483) from 60 seconds to 3 seconds.
9. Increased MAX_RETRY_COUNTS from 3 to 5 times. 10. The example HTTP server now returns a content expiration date which has already past. This prevents web browser caching and allows more dynamic content to be displayed. 11. Added WebPages_JScript folder, with new web pages that support dynamic page updates without a full page reload. A tiny page of dynamic variables is returned by the web server and Javascript executing on the target web browser changes DOM elements as needed. Button S5 (RA7) on the Explorer 16 demo board and S1 (RB0) on the HPC Explorer demo board changes the page color scheme. The rapid dynamic updates do not work on some web browsers (Internet Explorer works, Firefox does not). Known Problems: 1. MPFS utility has not been updated. When creating a .c image file, the include path for the compiler.h file will be incorrect and need to be manually updated. 2. When an MPFS .c image file is added to a C30 project, a linking error reporting insufficient contiguous .const memory may occur (PSV window size limitation). 3. MACSetPMFilter(), MACDisablePMFilter(), and MACCopyRxToTx() have not been tested and possibly do not work. 4. SNMP, TFTPc, SLIP modules have not been tested with this version. 5. Serial numbers >32K will be displayed on the serial port as a negative value when C18 is used and the board is placed in configuration mode (RB0 button is depressed on power up). 6. IP Gleaning may not get disabled when, through the RS232 configuration application, DHCP and IP Gleaning are disabled. 7. The IP address being outputted out the RS232 port and through the Announce ( happen when the IP address is configured using IP Gleaning. see page 152) module does not
8. On the PIC24F with C30 compiler optimizations enabled (such as Option 3, maximum speed), the project may not work. The PIC24F headers that come with C30 ver. 2.01 declare several SFRs without using the volatile keyword. 9. dsPIC30 support is incomplete. Currently PIC18, PIC24F, PIC24H, and dsPIC33F processors are supported.
45
****** v3.16.00: 06 March 2006 ****** Changes: 1. Added unified support for both the Microchip C18 and C30 compilers. The intention is to allow one code base to be compiled for any PIC18, PIC24F/H, dsPIC30, or dsPIC33 product (with adequate memory). See the "Tested Using" section for what is known to work. 2. To improve maintainability, support for the HI-TECH PICC18 compiler has been dropped. 3. New project workspaces have been created, "C30EEPROM.mcw" and "C18EEPROM.mcw". C18EEPROM.mcw is equivalent to the previously named "mpnicee.mcw." C30EEPROM is intended to be used for PIC24 and dsPIC 16-bit controllers. 4. Source files have been split into separate directories. 5. Latest ENC28J60 rev. B5 errata workarounds added. The code checks the EREVID register and implements the appropriate workarounds as needed for the silicon revision, so rev. B1, B4, and B5 are all supported in this stack release. 6. Removed old LCD code originally provided for the PICDEM.net demo board. 7. To improve maintainability, built in support for the "Compatable" A/D converter present on older PIC18 parts (ex: PIC18F452) has been removed. 8. UART functions in MainDemo.c were replaced with C18 and C30 peripheral library functions. Tested Using: 1. Software: -MPLAB version 7.31.01 -C18 version 3.02 -C30 version 2.01 2. Hardware: -PICDEM HPC Explorer rev. 4 (PIC18F8722) + Ethernet PICtail Daughter Board (ENC28J60 B1) -Explorer 16 rev. 4 (PIC24FJ128GA010 ES and dsPIC33FJ256GP710 ES) + Ethernet PICtail+ Daughter card (ENC28J60 B1). 3. Notes: -MPLAB 7.31.01 is a development build. The publicly available version 7.31 should work fine, with the exception of being unable to program dsPIC33 and PIC24H parts with the ICD 2. -No dsPIC30 or PIC24H parts have been tested yet. Known Problems: 1. MPFS utility has not been updated. When creating a .c image file, the include path for the compiler.h file will be incorrect and need to be manually updated. 2. When an MPFS .c image file is added to a C30 project, a linking error reporting insufficient contiguous .const memory may occur. 3. On the PIC24FJ128GA010, it is observed that some inbound packets are lost from time to time with no anticipated reason. 4. MACSetPMFilter(), MACDisablePMFilter(), and MACCopyRxToTx() have not been tested and possibly do not work. 5. SNMP, TFTPc, SLIP modules have not been tested with this version. 6. Serial numbers >32K will be displayed on the serial port as a negative value when C18 is used and the board is placed in configuration mode (RB0 button is depressed on power up). 7. IP Gleaning may not get disabled when, through the RS232 configuration application, DHCP and IP Gleaning are disabled. 8. The IP address being outputted out the RS232 port and through the Announce ( happen when the IP address is configured using IP Gleaning. see page 152) module does not
9. Multiple TX buffer support is not fully inplemented in the MAC layer, ENC28J60.c. Stack behavior when TCP_NO_WAIT_FOR_ACK is undefined may be unexpected.
****** Fixes: 1. Changed TXSTART in ENC28J60.c to stop wasting a byte. 2. Changed RXSTOP in ENC28J60.c to always be an odd value to properly implement an ENC28J60 silicon errata workaround. 3. Changed initialization of ERXRDPT in MACInit() to agree with the current errata. Changes: 1. Licence agreement 2. Schematics and other board files to the Ethernet PICtail Daughter Board have been updated to revision 5. Of significant note, the nRESET pin has been freed and 200 ohm resistors were added to the ENC28J60 SI, nCS, and SCK pins. The added resistors reduce undershoot caused by stray trace inductance and strong host output drivers. Known Problems: 1. Testing on the PICDEM.net demo board with the Realtek RTL8019AS Ethernet controller has not been done. Moving to the HPC Explorer demo board has resulted in pinout and other hardware changes. 2. MACSetPMFilter(), MACDisablePMFilter(), and MACCopyRxToTx() have not been tested and possibly do not work. 3. SNMP, TFTPc, LCD, SLIP modules have not been tested with this version. 4. The stack may behave incorrectly if compiled using the Hitech compiler with a high optimizations setting. 5. Serial numbers >32K will be displayed on the serial port as a negative value when C18 is used and the board is placed in configuration mode (RB0 button is depressed on power up). 6. IP Gleaning may not get disabled when, through the RS232 configuration application, DHCP and IP Gleaning are disabled. 7. The IP address being outputted out the RS232 port and through the Announce ( happen when the IP address is configured using IP Gleaning. see page 152) module does not
8. Multiple TX buffer support is not fully inplemented in the MAC layer, ENC28J60.c. Stack behavior when TCP_NO_WAIT_FOR_ACK is undefined may be unexpected.
****** v3.01.00: 18 Jan 2006 ****** Fixes: 1. Implemented latest ENC28J60 silicon errata workarounds. 2. Fixed a bug in TCP.c and UDP.c which would incorrectly write the packet checksum into the RX buffer incorrectly when the checksum field was exactly spanning the RX wrapparound boundary in the ENC28J60. This problem would have caused packets to be discarded in rare circumstances Known Problems: 1. Testing on the PICDEM.net demo board with the Realtek RTL8019AS Ethernet controller has not been done. Moving to the HPC Explorer demo board has resulted in pinout and other hardware changes. 2. MACSetPMFilter(), MACDisablePMFilter(), and MACCopyRxToTx() have not been tested and possibly do not work. 3. SNMP, TFTPc, LCD, SLIP modules have not been tested with this version. 4. The stack may behave incorrectly if compiled using the Hitech compiler with a high optimizations setting. 5. Serial numbers >32K will be displayed on the serial port as a negative value when C18 is used and the board is placed in configuration mode (RB0 button is depressed on power up). 6. IP Gleaning may not get disabled when, through the RS232 configuration application, DHCP and IP Gleaning are disabled. 7. The IP address being outputted out the RS232 port and through the Announce ( see page 152) module does not 47
Microchip TCP/IP Stack Help happen when the IP address is configured using IP Gleaning. 8. Multiple TX buffer support is not fully inplemented in the MAC layer, ENC28J60.c. Stack behavior when TCP_NO_WAIT_FOR_ACK is defined may be unexpected.
****** v3.00.00: 16 Jan 2006 ****** Changes: 1. The stack now targets the PICDEM HPC Explorer demo board (PIC18F8722 MCU) with an attached Ethernet PICtail Daughter Board (with the Microchip ENC28J60 Ethernet controller). 2. IP Gleaning is no longer enabled (STACK_USE_IP_GLEANING is not defined) by any of the default project files. 3. The IP address, whenever it changes, is outputted out the RS232 serial port in human readable form. Any terminal program, such as HyperTerminal can be used to read it. This allows the IP address to be easily determined when DHCP is used. The serial port defaults to 19200 baud when CLOCK_FREQ in Compiler.h is properly defined. Additions: 1. Microchip ENC28J60 Ethernet controller support. Support is included through the ENC28J60.c and ENC28J60.h files. Various other files were modified to take advantage of ENC28J60 specific features, like the hardware DMA/IP checksum engine. This new MAC driver incorporates several new functions which can be called from any layer above the MAC. The functions are: MACSetDuplex() MACPowerDown() MACPowerUp() MACSetPMFilter() MACDisablePMFilter() CalcIPBufferChecksum ( see page 213)() MACCalcRxChecksum() MACCalcTxChecksum() MACCopyRxToTx() See the ENC28J60.c file comments for function descriptions. The ENC28J60.c file also incroporates TestMemory() which can do a power on self test of various hardware functions. TestMemory() is included and used when MAC_POWER_ON_TEST is defined in StackTsk.h. It is undefined by default. Defining it will require some program memory. 2. Announce ( see page 152) module. Announce.c and announce.h have been added. When included in the project, STACK_USE_ANNOUNCE must be defined. This module will broadcast a UDP message to port 30303 containing the local MAC address whenever the local IP address changes. This addition is intended to facilitate device discovery on DHCP enabled networks and eliminate the need for an RS232 connection if board reconfiguration is not needed. To retrieve the UDP message on your computer, use the new MCHPDetect.exe program included in the MCHPDetect subfolder. 3. The spieeprom.c file was added to support SPI EEPROM chips for MPFS storage. ENC28J60.c and spieeprom.c may both be included and they will share the same SPI module. Improvements: 1. Renamed files/edited files so that the HI-TECH compiler won't raise messages stating that include files were spelled wrong. 2. Moved MAX_ICMP_DATA_LEN from StackTsk.c to ICMP.h file for easier maintenance. 3. Corrected STACK_USE_SIIP typo in dhcp.c file - Thanks to Gisle J.B. 4. Implemented UDP checksum logic in UDPProcess ( see page 534)() in UDP.c file. see page 213)().
7. Modified UDPProcess ( see page 534)() in UDP.c and TCPProcess ( see page 468)() in TCP.c to include localIP as third new parameter. This makes pseudo header checksum calculation correct in both functions. StackTsk.h, UDP.h and TCP.h files were also modified to reflect these changes. 8. Modified TCP.C file to include compile-time check of STACK_USE_TCP define. If it is not defined, an error will be displayed. 9. Removed an unnecessary call to MACDiscardRx() when an IP packet is received but fails version, options length, or header checksum tests. 10. Changed LCD code to be compile time removable by undefining USE_LCD. Fixes: 1. IPHeaderLen in IP.c is initialized properly now when IPGetHeader() is called. 48
Microchip TCP/IP Stack Help 2. Under some circumstances, HandleTCPSeg ( see page 473)() would acknowlege, but throw valid received TCP packets away, resulting in loss of application data. An invalid comparison in HandleTCPSeg ( see page 473)() has been fixed to prevent this situation from occuring. *** Thanks go to Richard Shelquist for identifying this problem. 3. Fixed StackTsk.c file so that if a static IP address is used and the LINK is removed, the node IP address is not cleared. 4. Invalid ICMP echo replies are no longer generated for echo requests with a data length of 33 (one more than the configured maximum). 5. Changed MAX_OPTIONS_LEN from 20 to 40. The maximum IP options length is now in agreement with the IP RFC. 6. Changed IPSetRxBuffer() from a macro to a function. The function takes into account any options which may be present in the header of received IP packets. Previously, possible options were not taken into account when calculating the offset. Known Problems: 1. Testing on the PICDEM.net demo board with the Realtek RTL8019AS Ethernet controller has not been done. Moving to the HPC Explorer demo board has resulted in pinout and other hardware changes. 2. Sometimes when the FTP sever is used, an attempt to put a file is unsuccessful. The problem may be caused when an HTTP request to GET a file is made at the wrong time. 3. MACSetPMFilter(), MACDisablePMFilter(), and MACCopyRxToTx() have not been tested and possibly do not work. 4. SNMP, TFTPc, LCD, SLIP modules have not been tested with this version. 5. The stack may behave incorrectly if compiled using the Hitech compiler with a high optimizations setting. 6. Serial numbers >32K will be displayed on the serial port as a negative value when C18 is used and the board is placed in configuration mode (RB0 button is depressed on power up). 7. IP Gleaning may not get disabled when, through the RS232 configuration application, DHCP and IP Gleaning are disabled. 8. The IP address being outputted out the RS232 port and through the Announce ( happen when the IP address is configured using IP Gleaning. see page 152) module does not
9. Multiple TX buffer support is not fully inplemented in the MAC layer, ENC28J60.c. Stack behavior when TCP_NO_WAIT_FOR_ACK is defined may be unexpected.
****** v2.20.04.01: 9/24/03 ****** 1. Recreated MPLAB projects to avoid problems when source is not at MCHPStack location.
****** v2.20.04: 9/5/03 ****** Fixes: 1. Modified DHCPReset() in DHCP.c to not reset DHCP state machine if it was previously disabled using DHCPDisable(). This would make sure that if DHCP module was enabled and application had run-time disabled DHCP and network cable is disconnected, stack will not clear its IP address.
2. Rebuilt mib2bib.exe file with static library options. This fixes problem where one tries to execute this exe, an error occurs about missing DLLs.
49
****** v2.20.03: ****** Improvements: 1. When DHCP is enabled, LINK is monitored and IP address is reset on disconnect. New IP configuration is obtained on LINK reconnect. - For RealTek only. Modified DHCP.c to add DHCPReset() Modified MAC.c to add MACIsLinked() Modified StackTsk.h to add BYTE_VAL def. Changes: 1. Modified SMSC91c111.c to add empty MACIsLinked() - will be populated in next rev. Bug Fixes: 1. Corrected DHCP logic to accept ( see page 166) first DHCP offer instead of second response.
2. Corrected DHCP logic to check for chaddr in DHCP offer and accept ( see page 166) one that matches with local MAC address. This will fix problem where if multiple nodes were on bus and all requested DHCP address, all would accept ( see page 166) response from one server instead of verifying who was intended node. 3. Fixed UDPClose ( see page 525)() in UDP.c to use INVALID_UDP_PORT ( see page 522) instead of INVALID_UDP_SOCKET ( see page 522) because of which a closed socket would not be scanned correctly. 4. Modified UDP.h to use long contsant designators for INVALID_UDP_OPRT to explicitly state that it is a long.
****** v2.20.02: ****** Beta version containing TFTP client module. Addition: 1. TFTP Client module - See TFTPc.* and TFTPcDemo.c for more information. See MpTFTPcDemo and HtTFTPcDemo projects for build information. Bug Fix: 1. UDPIsGetReady ( see page 527)() was modified to overcome compiler rule where only 8-bit value was used to evaluate non-zero condition. 2. ARPResolve ( see page 155)() in ARPTsk was fixed to clear Cache.IPAddr value.
****** v2.20.01: ****** Bug fix: 1. Fixed SMSC91C111.c where MACInit() would hand if ethernet link is not detected.
****** v2.20:
50
****** Bug Fixes: 1. General - Removed most of harmless warnings. 2. C18Cfg.asm - Fixed "include" instead of "define". 3. DHCP.c - Increased DHCP_TIMEOUT_VAL to 2 seconds. Fixed problem where UDP active socket was not set before calling UDP functions in SM_DHCP_BROADCAST state. 4. MAC.c - Fixed MACIsTxReady() where under heavy traffic it would always return FALSE. This fixes bug where all high level applications would stop transmitting. 5. TCP.c - Enabled portion of code that performs timeout logic even if TCP_NO_WAIT_ACK is defined. This fixes bug where occasionally, tcp applications such as HTTP server would stop working after few hours. 6. UDP.c - Fixed UDPGet ( see page 526)() where it would return FALSE on last good byte. Fixed UDPProcess ( page 534)() where it was calculating incorrect length. see
Added bFirstRead flag with UDP sockets similar to TCP sockets so that whenever first UDP byte is read, MAC read pointer will be reset to begining of correct packet. This change fixes problem where if one transmits a packet while UDP packet is pending in a socket, next get to pending UDP socket would return wrong data. (This is apparent only when there is heavy network traffic) Known Issues: 1. HiTech v8.20 PL4 with all optimization enabled may not work properly. 2. C18 "Static" and "Auto" mode may not be used - there are too many local variables to fit in standard stack of 256 bytes. One may modify linker script file to avoid this limitation.
Improvements: 1. Modified TICK def. in Tick.h to unsigned long to support 32-bit wide SNMP tick. 2. Added SNMP Module (SNMP.c) 3. Added Two new demo projects - DemoSNMPApp and HtDemoSNMPApp. 4. Created MPLAB 6.X projects for different demo configurations. 5. MAC.c - Added MACGetTxOffset(). 6. MPFS.c - Added MPFSSeek ( see page 280)(), MPFSTell ( see page 285)().
7. MPFSImg.*- Rebuilt to reflect v2.20, footprint changes etc. 8. StackTsk.h- Enhanced WORD_VAL, DWORD_VAL defs. Added STACK_USE_SNMP and related compile-time checks. 9. UDP.h - Added UDPSetTx and UDPSetRx macros. Moved UDP_SOCKET_INFO ( file. see page 538) structure to header
10. WebSrvr.c- Modifed MCHPStack version message and added DATE info to BoardSetup menu. 11. Added support for SMSC LAN91C111 10/100 Non-PCI ethernet controller Use "SMSC91C111.C" instead of MAC.c. "mpnicee_smsc" is a sample project that uses PIC18F8720 and SMSC NIC. "MasterDemo.c" is a main source file for above project that includes all modules - must use device with more than 32KB of memory.
****** v2.11:
51
****** Bug Fixes: 1. Fixed dhcp.c to make it work with new C18 startup code. Improvements: 1. Modified websrvr.c DownloadMPFS() to make use of compiler allocated XMODEM data block rather than use fixed address block starting at 0x400.
****** v2.10: 7/9/02 ****** Bug Fixes: 1. Fixed HTTP Server bug where a form submission with empty parameter value would not parse correctly.
****** New Modules: ****** 1. Added UDP, DHCP, FTP and IP Gleaning 2. Added PICDEM.net LCD support 3. Added board setup through RS-232.
****** Improvements: ****** 1. Optimized serial EEPROM access routines in terms of speed and size (Replaced ee256.* files with eeprom*.h) 2. Improved board setup through RS-232.
****** Known Issues: ****** 1. LCD may not display properly on MCLR only. Workaround: 1. Debug XLCDInit() routine in "xlcdlh" 2. Always do POR reset.
52
Microchip TCP/IP Stack Help 2. SLIP connection is not very robust. Workaround: None at this time.
3. Hi-Tech Compiler: 1. Aggressive optimization breaks the functionality. Workaround: Apply optimization listed in each source file comment header. 2. In order to use V8.12, you will need to remove "FTP Server" from Ht*.pjt. You will also need to disable all optimizations.
4. C18 Compler: 1. Static model does not compile. Workaround: None at this time. 2. Overlay model breaks the functionality. Workaround: None at this time. 3. All modules does not fit in 32KB memory. Workaround: 1. None at this time. 2. Sample project disables some modules.
****** New Files: ****** ======================================================================================== ==================================== File Purpose ======================================================================================== ==================================== 1. delay.* Provides CLOCK_FREQ depenent delay routines. 2. dhcp.* DHCP client support 3. ftp.* FTP server 4. udp.* UDP socket support 5. xeeprom.* Improved ee256.* and renamed. 6. xlcd.* External LCD support. 7. version.log To track changes and history.
****** Changes: ****** ======================================================================================== ==================================== File Change To-do for v1.0 stack applications ======================================================================================== ==================================== 1. arptsk.c 1. Fixed STACK_CLIENT_MODE compile errors. None 2. Modifed ARPIsResolved ( None see page 156)() to support IP Gleaning
3. compiler.h 1. Included "stdlib.h" in both C18 and Hi-Tech compilers. None 2. Moved CLOCK_FREQ from "stacktsk.h" to this file. None 3. Added PORTA defs. None
4. htnicee.pjt 1. Removed "ee256.c". None 2. Added "udp.c", "dhcp.c", "ftp.c", "xlcd.c", "xeeprom.c" files Add these files if needed.
5. htnicpg.pjt None
6. htslee.pjt 1. Removed "ee256.c". None 2. Added "ftp.c", "xlcd.c", "xeeprom.c" files None
7. http.c 1. Included compile-time verification that HTTP module is included. None 2. Put HTTP message strings into one array "HTTPMessages". None 3. Modified to return "Service Unavailable" message if MPFS is being None remotely programmed. 4. Modified SendFile() to make use of sequential EEPROM read. None
8. ip.c 1. Added one more paramter to IPGetHeader() to support IP Gleaning Custom apps using IP needs to be modified.
9. mac.c 1. Replaced fixed delay routines with CLOCK_FREQ dependent None routines
54
Microchip TCP/IP Stack Help 10. mpfs.c 1. Replaced ee256.h with xeeprom.h. None 2. Added MPFSFormat ( None 3. Added sequential read and page write operations Custom apps using MPFS directly needs to be modified. 4. Defined MPFS_WRITE_PAGE_SIZE ( Apps using different EEPROM page size needs to be modified. see page 284) for MPFSPut operations. see page 271)(), MPFSPut() etc. routines
11. mpnicee.pjt 1. Removed "ee256.c" None 2. Added "xcld.c", "xeeprom.c" files None
12. stacktsk.c 1. Replaced ee256.h with xeeprom.h None 2. Added IP Gleaning and DHCP support. None
13. stacktsk.h 1. Moved CLOCK_FREQ to compiler.h None 2. Added STACK_USE_DHCP, STACK_USE_FTP_SERVER etc. options None 3. Added compile-time enable/disable of modules based on selection of higher level modules. None 4. Modified MY_DEFAULT_MAC_BYTE? to use Microchip OUI id. None 5. Added compiler-time check to confirm available TCP sockets None 6. Added MSB and LSB macros. None 7. Added SerialNumber etc. to AppConfig structure None 8. Commented module selection defines: They are defined by cmopiler None command-line options. Real application should define them here in this file.
55
3.2 Memory Usage 2. Fixed TCPIsConnected ( None 3. Fixed TCPDisconnect ( None see page 446)() see page 453)()
4. Modified TransmitTCP() to set receive window of one segment None 5. Modified TransmitTCP() to use max segment size equal to predefined value. None 6. Improved TCP State machine None
15. tick.c 1. Modified TICK type to 16-bit. None 2. Made use of TICK_PRESCALE_VALUE None 3. Added code to blink PICDEM.net "System LED" Remove if not required.
16. websrvr.c 1. Added LCD support N/A 2. Made TickUpdate ( N/A 3. Added code to save/restore board configuration N/A 4. Added board setup via RS-232. N/A 5. Added call to FTP modules If needed, add this. see page 518)() on Timer0 interrupt
memory required to implement specific modules. These values are approximations; the program memory size may increase depending on application code, or decrease based on optimizations of modules with overlapping code. Modules that require user-implemented API functions (SNMP, HTTP) are tested without additional code. The global data memory column includes only the RAM needed for the required structures in the stack; it does not include the memory used for socket allocation ( see page 149). The C18 code uses the PIC18F97J60 family Ethernet controller as the MAC/PHY chip; the C30 and C32 measurements are made using the ENC28J60 Ethernet controller (ENCX24J600 sizes are similar). All compilers include a separate Required Stack Code line for Wi-Fi applications using the MRF24WB0M as the network controller. These two Required Stack Code lines are mutually exclusive -- do not add them together. Instead, chose the line representing your network controller. These values are approximations obtained from TCP/IP Stack version 5.31. Note that these tables will not appear in the PDF version of the help file; see the "TCPIP Cxx Memory Usage.htm" files in the TCPIP documentation folder in the Microchip Application Library help folder. C18 C30 C32
Select via #define in HardwareProfile.h. Polled. See Hardware Configuration ( see page 139). Select via #define in HardwareProfile.h. Polled. See External Storage ( see page 139).
SPI
Select via #define in HardwareProfile.h. Polled. See External Storage ( see page 139).
57
4 Silicon Solutions
One of the first choices to make when designing your application is which hardware layer to use. Microchip supports a number of hardware TCP/IP solutions, each with an integrated MAC and/or PHY. The ENC28J60 and ENCX24J600 are stand-alone Ethernet controller chips, developed by Microchip Technology. The MRF24WB0M is a stand-alone 802.11b wireless transceiver. The PIC18F97J60 is a PIC18 microcontroller with an integrated Ethernet peripheral. The PIC32MX7XX/6XX series of 32-bit microcontrollers are high performance devices with integrated Ethernet MAC peripheral (MII/RMII interface to external PHY). For information about demonstration boards that use these devices, see the Demo Kits ( Feature Technology MAC PHY RAM (bytes) Interface ENC28J60 ENCX24J600 PIC18F97J60 Wired Ethernet Internal Internal (10-Base-T) 3,808 see page 64) section.
MRF24WB0M PIC32MX7XX/6XX 802.11 Wireless Internal Internal 14,170 Wired Ethernet Internal External PHY Interface) (MII/RMII
Wired Ethernet Wired Ethernet Internal Internal (10-Base-T) Internal Internal (10/100-Base-T) 24,576
Buffer 8,192
Configurable descriptors in Internal RAM (128k of Internal RAM) None MAC) (built-in Ethernet
SPI
Pins Package
28
64/100/121
SOIC, SPDIP, TQFP, QFN SSOP, QFN (6x6 mm) No Yes Yes
Surface TQFP, QFN (9x9 mm), BGA Mount WiFi I/O module No Yes No Yes
Cryptographic Engines
No No(1)
1: For devices without a pre-programmed MAC address, you may consider using an EEPROM with a built-in MAC address, such as the device family described here ( see page 144).
58
5 Software
This section will discuss the computer software applications included with Microchip's TCP/IP Stack. These tools are implemented using the C# or Java programming languages, or both. The C# tools (*.exe) will require the Microsoft .NET Framework v2.0 to be installed on the local PC. The Java tools (*.jar) require Java Runtime Environment (JRE) 1.6 or later to be installed on the target computer.
storage device using the upload functionality built into the HTTP2 web server or FTP server. The source code for this application is included in the Microchip Applications Libraries installer.
Step 2 selects the output format. If storing the web pages in external EEPROM or serial Flash, choose the BIN Image output format. If internal program memory will be used, select C18/C32 Image for use with 8-bit and 32-bit parts, or ASM30 Array for 16-bit targets. To store the web pages on a device formatted with the FAT file system without compressing them into an MPFS image, select MDD (see the Demo App MDD Getting Started guide for more information).
Step 3 asks for the MPLAB IDE project directory. The MPFS tool will write the image file to the project directory, and will also update the HTTPPrint.h file there if needed. Select the correct directory so that the right files are modified.
Step 4 controls the upload settings. When external EEPROM or serial flash is used for storage, the option to upload the newly created image to the board is available. Check the box next to Upload Image To to enable this feature. The target host name (or IP address), upload protocol, and upload path may need to be changed to the one chosen when the board was first configured. You may also need to modify the user name and password used to access the secured functionality in your application, like web page upload. Use the Settings button to edit these values. If internal program memory is being used, the image will be compiled in with the project and so direct uploads are not available. Make sure to include the output source file indicated in step 3 as part of the project.
Once all the correct settings have been chosen, click the Generate button to create the image. If uploads are enabled, this will also attempt to upload the file to the device.
Steps 2 and 3 are not required for pre-built images. Proceed directly to step 4 and verify that the upload settings are correct. The target host name (or IP address), upload protocol, and upload path may need to be changed to the one chosen when the board was first configured. You may also need to modify the user name and password used to access the secured functionality in your application, like web page upload. Use the Settings button to edit these values. Once all the settings are correct, click the Upload button. The image will be uploaded to the board.
The Dynamic Files list indicates which file types to parse for dynamic variables. By default, all files with the extensions htm, html, cgi, or xml are parsed. If an application has dynamic variables in other file types, these types must be added to the list. This field must be a comma-separated list of extensions and file names. The Do Not Compress field indicates which file types should never be compressed. Compressing files with GZIP saves both storage space and transmission time. However, this is only suitable for static content such as CSS or JavaScript. Any files with dynamic variables will automatically be excluded. In addition, any file that the PIC may need to process internally should be excluded. Files included via ~inc:filename~ should not be compressed, nor should any BIB file used for the SNMP module (if present). Additional file types can be added to this list if a custom application will be accessing the MPFS. The GZIP compressor will attempt to shrink all files. In some cases, especially with images, little or no compression is achieved. When this occurs the file is stored as-is in the MPFS image.
Description Output a BIN image (Default) Output a C18 or C32 image Output an ASM30 image Use the MPFS2 format (Default) File types to be parsed for dynamic variables (Default: "*.htm, *.html, *.cgi, *.xml") File types to be excluded from GZIP compression (Default: "*.bib, *.inc")
The command-line interface does not support image uploads. For batch or production uploads, use a tool such as wget to upload the generated BIN image.
62
63
Daughter Boards
6 Getting Started
This section describes the steps necessary to begin using Microchip's TCP/IP Demo Applications. This section contains specific information for setting up and using the generic TCPIP Demo App ( see page 83). Most of this setup information can be applied to get started with other demo applications as well.
The Ethernet PICtail Daughter board is populated with an ENC28J60, an RJ-45 connector (with integrated magnetics), and the few other components required for Ethernet operation. It provides a 10-Base-T Ethernet connection for any demo board with a PICtail connector. This daughter board has been largely superseded by the PICDEM.net 2 ( see page 65) for debugging Ethernet applications using the PIC18. Visit the Microchip web site to view the Ethernet PICtail Product Page. Ethernet PICtail Plus Daughter Board
The Ethernet PICtail Plus Daughter Board is the PICtail Plus version of the Ethernet PICtail Daughter Board. It allows the 64
PICDEM.net 2
interface of an ENC28J60 to any demo board with a PICtail Plus connector. Visit the Microchip web site to view the Ethernet PICtail Plus Daughter Board Product Page. Fast 100Mbps Ethernet PICtail Plus Daughter Board
The Fast 100Mbps Ethernet PICtail Plus Daughter Board provides a method for testing and demonstrating the ENC624J600 Ethernet Controller. The board is designed for flexibility and can be connected to a PICtail or a PICtail plus connector. In addition, it is designed to allow the use of any of the parallel or SPI connection modes featured on the ENC624J600 on the PICtail Plus connector. This daughter board provides 10/100-Base-T functionality. Visit the Microchip web site to view the Fast 100Mbps Ethernet PICtailTM Plus Daughter Board Product Page. Microchip 802.11b WiFi PICtail Plus Daughter Board
The Micorchip 802.11b WiFi PICtail Plus Daughter Board is a demonstration board for evaluating Wi-Fi connectivity on boards with a PICtail or a PICtail Plus connector. The board features the Microchip MRF24WB0MA module, which includes a Wi-Fi transceiver and associated circuit elements. Visit the Microchip Web Site to view more information on Wireless Solutions and the 802.11b WiFi PICtail Product Page..
6.1.2 PICDEM.net 2
Visit the Microchip web site to view the PICDEM.net 2 Product Page. The PICDEM.net 2 development board comes populated with a PIC18F97J60 with an integrated Ethernet controller, as well as a standalone ENC28J60 Ethernet controller. The integrated controller is connected to the left Ethernet jack (closest to the LCD), and the standalone part is connected to the right one. By default the stack is configured to use the integrated controller, so the left port should be connected to the network cable. No other configuration of the board is necessary. The User's Guide that shipped with this development board may refer to an older version of the TCP/IP Stack. This document updates much of that documentation for version 5.36.4.
65
PICDEM.net 2
Using the Fast Ethernet PICtail By default, this board will use the ENC28J60 or the PIC18F97J60 for Ethernet communication. However, by connecting the Fast Ethernet PICtail to the PICtail connector on the board, you can use it to test the ENC624J600. To use the Fast Ethernet PICtail, insert it as shown in the picture, with header J4 on the PICtail inserted into connector J5 on the demo board.
The Fast Ethernet PICtail is designed to use the SPI communication bus when connected through a PICtail header, so the jumper settings are unused in this configuration, with one exception: the JP2 jumper on the PICtail, labeled ISENSE, should be shorted. The pre-compiled and pre-configured versions of the demo that correspond to this setup are already written to enable ENC624J600 functionality; for manual configuration information, see the ENCX24J600 ( see page 141) configuration page. Using the Microchip 802.11b WiFi PICtail The PICDEM.net 2 can be used to debug wireless functionality by connecting the PICtail as show in the picture, with header J1 on the PICtail inserted into connector J5 on the demo board.
Note if jumper JP3 exists, it must be shorted between pins 2 and 3 when used on this development platform. 66
PIC18 Explorer
Once your hardware is configured, you can program your board with your preferred demo project. The next few topics ( see page 71) in the Getting Started section of this help file provide a tutorial for setting up the generic TCPIP demo application.
Using the Ethernet PICtail Unlike the PICDEM.net 2, the PIC18 Explorer does not include an ENC28J60 on the board. To enable testing and debugging using the ENC28J60, you must connect ( see page 168) an Ethernet PICtail, as shown in the picture (insert header J2 into connector J3 on the demo board).
When using this configuration, short pins 2 and 3 on jumper J9, to indicate that the PIC18 Explorer is providing a 5V power 67
supply. The pre-compiled and pre-configured versions of the demo that correspond to this setup are already written to enable ENC28J60 functionality; for manual configuration information, see the ENC28J60 ( see page 140) configuration page. Using the Fast Ethernet PICtail By connecting the Fast Ethernet PICtail to the PICtail connector on the board, you can use it to test the ENC624J600. To use the Fast Ethernet PICtail, insert it as shown in the picture, with header J4 on the PICtail inserted into connector J3 on the demo board.
The Fast Ethernet PICtail is designed to use the SPI communication bus when connected through a PICtail header, so the jumper settings are unused in this configuration, with one exception: the JP2 jumper on the PICtail, labeled ISENSE, should be shorted. The pre-compiled and pre-configured versions of the demo that correspond to this setup are already written to enable ENC624J600 functionality; for manual configuration information, see the ENCX24J600 ( see page 141) configuration page. Using the Microchip 802.11b WiFi PICtail The PIC18 Explorer can be used to debug wireless functionality by connecting the PICtail as show in the picture, with header J1 on the PICtail inserted into connector J3 on the demo board.
Note if jumper JP3 exists, it must be shorted between pins 2 and 3 when used on this development platform. Once your hardware is configured, you can program your board with your preferred demo project. The next few topics ( see page 71) in the Getting Started section of this help file provide a tutorial for setting up the generic TCPIP demo application.
68
2. Jumper J7 selects PIC24 (even though the label reads PIC24, this jumper setting selects the programming signals to any PIC on the Explorer 16).
The PIC32 Starter Kit performs a similar function for 32-bit PIC32 parts. By using the PIC32 I/O Expansion Board you can connect ( see page 168) the same PICtail Plus board that connect ( see page 168) to the Explorer 16.
Using the Ethernet PICtail Plus To enable testing and debugging of the ENC28J60 on these boards, you must connect ( see page 168) an Ethernet PICtail Plus, as shown in the picture (insert header J2 into the upper card-edge connector J5 (Explorer 16) or J4 (I/O Expansion Board)). Note that for some demos, the Ethernet PICtail Plus will need to be inserted into the center card-edge connector of the PICtail Plus connector to use the SPI2 module. See the Demo Compatibility Table ( see page 79) for more information.
69
The pre-compiled and pre-configured versions of the demo that correspond to this setup are already written to enable ENC28J60 functionality; for manual configuration information, see the ENC28J60 ( see page 140) configuration page. Using the Fast Ethernet PICtail Plus By connecting the Fast 10/100 Ethernet PICtail Plus to the PICtail Plus connector on your board, you can use it to test the ENC624J600. The Fast Ethernet PICtail Plus can be used with these boards in either serial (SPI) or parallel communication mode. For serial mode, connect ( see page 168) header J2 of the daughter board to connector J5 (Explorer 16) or J4 (I/O Expansion Board), as seen in the pictures. When operating in serial mode, the jumpers on the Fast Ethernet PICtail are unused, with one exception: the JP2 jumper on the PICtail, labeled ISENSE, should be shorted.
To use the Fast Ethernet PICtail Plus board in parallel mode, insert header J1 into connector J5 of the Explorer 16 or J4 of the I/O Expansion Board, as seen in the pictures. In this configuration, the jumpers must be shorted or opened corresponding to the parallel communication mode being used. A matrix outlining which jumper connections must be made for the jumpers labeled PSPCFG3, PSPCFG2, PSPCFG1&4, PMA to AD, and PMA to A is printed on the back side of the daughter board.
The pre-compiled and pre-configured versions of the demo that correspond to this setup are already written to enable ENC624J600 functionality; for manual configuration information, see the ENCX24J600 ( see page 141) configuration page. Using the Microchip 802.11b WiFi PICtail The Explorer 16 and PIC32 Starter Kit can be used to debug wireless functionality by connecting the PICtail as show in the pictures, with header J2 on the PICtail inserted into the top slot of connector J5 (Explorer 16) or J4 (I/O Expansion Board) on the demo boards.
70
Note if jumper JP3 exists, it must be shorted between pins 1 and 2 when used on this development platform. Once your hardware is configured, you can program your board with your preferred demo project. The next few topics ( see page 71) in the Getting Started section of this help file provide a tutorial for setting up the generic TCP/IP demo application.
You can add network connectivity to this demo board by inserting an Ethernet PICtail Plus, Fast Ethernet PICtail Plus, or Microchip 802.11b WiFi PICtail into the PICtail Plus connector on the demo board. The method for doing this is functionally identical to the method used for the Explorer 16 and PIC32 Starter Kit ( see page 68).
1. From the "File" menu, select "Import." Browse to the Precompiled Hex subdirectory in your demo project directory and select the *.hex file that matches your hardware setup. The hex file names describe the hardware that the file has been compiled for. For example, the file "Microchip Solutions v2011-06-02\TCPIP\Demo App\Precompiled Hex\C18-PICDN2_ETH97 18F97J60.hex" corresponds to the generic TCP/IP Demo application for the PIC18F97J60 on the PICDEM.net 2, using the PIC's internal Ethernet module. A document enumerating the abbreviations used in the hex file and project file names is available in the Microchip Solutions v20xx-xx-xx/Help directory. 2. Verify that the MPLAB IDE processor target selection and linker script (if one is present) match the part on your demonstration board (ex: PIC18F97J60). Note that the projects and source code used to build each hex file are present in the project directory. The hardware and firmware configuration files used to build each project are included in the Configs subdirectory. Programming Select your device programmer from the Programmer menu in MPLAB, and then use the Program shortcut button or the Program menu option to program the code you imported to your board. Clearing the EEPROM The TCP/IP Stack stores network configuration settings (such as the host name, MAC address, default static IP addresses, SNMP strings, WiFi network name (SSID), etc) in external EEPROM on the board. The demo project will detect if the default values have been changed in the EEPROM, and if so, use the new values. If not, the demo will use the default values configured in TCPIPConfig.h and WF_Config.h. Checksums stored in the EEPROM are used to determine if the structures stored in EEPROM are valid. Manually clearing the EEPROM will allow the demo to resume using the default settings. Use the following procedure to clear the EEPROM: 1. Make sure the development board is programmed and not in debug mode 2. Disconnect the MPLAB ICD 2/3 or MPLAB REAL ICETM from the board 3. Press and hold BUTTON0 (RD13/S4 on Explorer 16 or RB3/S5 on PICDEM.netTM 2) 4. Press and release the MCLR button 5. Continue holding BUTTON0 until several LEDs flash indicating that EEPROM has been cleared. This takes about 4 seconds. 6. Release BUTTON0 7. Press and release MCLR again to reset the software Once you see LED0 (right-most LED) blinking, the software is running and ready for use. If you are using the MRF24WB0M WiFi PICtail, you'll need to configure your wireless access point ( all Ethernet devices, Connect your Development Board ( see page 74) to your network. see page 72) first. For
72
Wireless Setup Along the top of the webpage, there should be many tabs for all the different features of the access point. One of the tabs should read "Wireless". After clicking the tab, you will be presented with the Wi-Fi protected setup page. You'll need to click the manual tab to be able to enter your own wireless settings to match the demo.
The out of box demo is looking for an AP with the following parameters (note that the SSID is case sensitive): SSID Security Channel MicrochipDemoAP None Either 1, 6, or 11
73
Once the network is setup, you can connect your device to the network (
host name uses the NetBIOS Name Service ( see page 287). It is only available on your local subnet, and will not be accessible from the Internet. Note that this service is not supported by all operating systems. If you have difficulty accessing your board, try using the IP address shown on the LCD screen instead (e.g. access the board at http://192.168.1.101). You can also determine the IP address by using the Microchip TCP/IP Discoverer ( see page 62). Open a web browser and access the board at http://mchpboard/mpfsupload. This form will allow web pages stored on the device to be updated. If you mistype this URL, the board will provide a default HTTP 404 error page with a link to the MPFS Upload page. This default 404 page will not appear if you've configured your browser to override custom error pages (e.g. by checking "Show friendly HTTP error messages" in Internet Explorer 7's internet options menu). Select the file MPFSImg2.bin from the TCPIP\Demo App folder as shown below. This update method is only available when using external storage.
When the Upload button is clicked, the MPFS image is sent to the board and programmed into the EEPROM. As this happens, the activity LED on the Ethernet jack will blink. Once the browser reports that the upload has completed, click the link provided within the status message to access the board's web pages. You can now Access the Demo Application ( see page 75).
75
If you attempt to access the Network Configuration or SNMP Configuration web pages from the red menu on the left, you will be prompted for a username and password. The default username is "admin" and the default password is "microchip". More information is available on the Authentication ( see page 86) web page, or in the HTTP2 server authentication ( see page 233) help topic. Some features of the default demo application may not be available on certain hardware platforms. For more information, see the TCPIP Demo App Features by Hardware Platform ( see page 83) topic. For information about how to use each feature of the TCP/IP Demo Application, consult the subtopics in the TCP/IP Demo Application Demo Modules ( see page 84) topic. Once you have finished exploring the demo application, you can proceed to the Stack API ( more about the stack and start developing your own application. see page 152) section to learn
If you are exploring the Wi-Fi demo applications and want to set up security, you can get more information on the WLAN security page ( see page 76).
76
WF_SECURITY_WEP_40
40-bit WEP security. This equates to 5 ASCII characters or 10 hex digits. MY_DEFAULT_WEP_KEYS_40 contains up to four keys that can be programmed (default is key 0). 104-bit WEP security. This equates to 13 ASCII characters or 26 hex digits. MY_DEFAULT_WEP_KEYS_104 contains up to four keys that can be programmed (default is key 0). Uses the 32 bytes in MY_DEFAULT_PSK as the key to join the network. These values are generated from a hash of the SSID name and WPA passphrase. For the purpose of the demo, the 32-bytes in MY_DEFAULT_PSK in WF_Config.h correspond to an SSID of "MicrochipDemoAP" and passphrase "Microchip 802.11 Secret PSK Password".
WF_SECURITY_WEP_104
WF_SECURITY_WPA_WITH_PASS_PHRASE Instructs the MRF24WB0M to generate the 32 byte PSK using the SSID and passphrase. The default in WF_Config.h corresponds to an WF_SECURITY_WPA2_WITH_PASS_PHRASE WF_SECURITY_WPA_AUTO_WITH_PASS_PHRASE SSID of "MicrochipDemoAP" and passphrase "Microchip 802.11 Secret PSK Password". Note that it takes approximately 30 seconds for the MRF24WB0M to calculate this value[1]. Note: Some routers try to increase the random nature of the WEP key by adding an additional layer that will convert an ASCII passphrase into a hexadecimal key. The MRF24WB0M PICtail will require a hexadecimal key, no matter which way it is generated. Access Point Security Settings The access point will also need to be changed to match the same security settings. Wireless security settings can be found in the "Wireless Security" tab under the main "Wireless" tab (example shows a Linksys WRT5G2). The drop-down box for security has all the different security options. Note that for WPA/WPA2, the MRF24WB0M only supports personal security levels (as opposed to enterprise, which is not supported).
[1]: Once the 32-byte PSK is calculated, it can be retrieved by the host from the MRF24WB0M. The host can then save this key to external non-volatile memory. On future connection attempts, the host can program the MRF24WB0M with the 77
WF_SECURITY_*_WITH_KEY options, provide the saved key, and not have to wait 30 seconds to reconnect to the network. Pre-generated PSK You also have the option to pre-generate the PSK and use the 32-byte PSK directly in the source code. One handy tool to generate the PSK can be found online at the Wireshark Foundation http://www.wireshark.org/tools/wpa-psk.html. The Wireshark website can generate the expected 32-byte PSK key with the SSID name and the passphrase. You can then use these values in the variable MY_DEFAULT_PSK in TCPIPConfig.h.
78
7 Demo Information
This section describes Microchip's TCP/IP Demo projects, including information about demo-hardware compatibility. For information about how to load and configure the demos, please consult the Getting Started section.
PIC18 Explorer PIC18 Explorer PIC18 Explorer PIC18 Explorer PIC18 Explorer PIC18 Explorer PIC18 Explorer PIC18 Explorer PICDEM.net 2 PICDEM.net 2 PICDEM.net 2 PICDEM.net 2 Explorer 16 Explorer 16 Explorer 16 Explorer 16 Explorer 16 Explorer 16 Explorer 16 Explorer 16
18F87J11 18F87J11 18F87J50 18F87J50 18F87J50 18F8722 18F8722 18F8722 18F97J60 18F97J60 18F97J60 18F97J60 24FJ128GA010 24FJ128GA010 24FJ128GA010 24FJ128GA010 24FJ256GA110 24FJ256GA110 24FJ256GA110 24FJ256GA110
ENCX24J600 MRF24WB0M ENC28J60 ENCX24J600 MRF24WB0M ENC28J60 ENCX24J600 MRF24WB0M ETH97J60 ENC28J60 ENCX24J600 MRF24WB0M ENC28J60 ENCX24J600 MRF24WB0M ENCX24J600 ENC28J60 ENCX24J600 ENCX24J600 MRF24WB0M
SPI SPI SPI SPI SPI SPI SPI SPI SPI SPI SPI SPI SPI SPI PSP Indirect SPI2 SPI2 PSP Indirect SPI2 5 5
79
SPI SPI PSP Indirect SPI SPI SPI PSP Indirect Bitbang SPI SPI SPI PSP Indirect SPI SPI SPI2 SPI2 SPI PSP Indirect PSP 9 SPI SPI SPI SPI SPI SPI SPI SPI SPI PSP Indirect Bitbang SPI SPI SPI PSP Indirect SPI 5 5 5 5 5 5
Explorer 16 Explorer 16 Explorer 16 Explorer 16 Explorer 16 Explorer 16 Explorer 16 Explorer 16 Explorer 16 Explorer 16 Explorer 16 Explorer 16 Explorer 16 Explorer 16 Explorer 16 Explorer 16 Explorer 16 Explorer 16 PIC24FJ256DA210 Board PIC24FJ256DA210 Board PIC24FJ256DA210 Board PIC24FJ256DA210 Board
24FJ256GB210 33FJ256GP710 33FJ256GP710 33FJ256GP710 33FJ256GP710 32MX360F512L 33EP512MU810 24EP512GU810 32MX360F512L 32MX360F512L 32MX360F512L 32MX360F512L 32MX460F512L 32MX460F512L 32MX460F512L 32MX795F512L 32MX795F512L 32MX795F512L Development 24FJ256DA210 Development 24FJ256DA210 Development 24FJ256DA210
MRF24WB0M ENC28J60 ENCX24J600 ENCX24J600 MRF24WB0M ENC28J60 ENC28J60 ENC28J60 ENCX24J600 ENCX24J600 ENCX24J600 MRF24WB0M ENC28J60 ENCX24J600 MRF24WB0M ENC28J60 ENCX24J600 MRF24WB0M ENC28J60 ENCX24J600 ENCX24J600
Development 24FJ256DA210
PIC32 General Purpose Starter Kit 32MX360F512L (DM320001) PIC32 General Purpose Starter Kit 32MX360F512L (DM320001) PIC32 General Purpose Starter Kit 32MX360F512L (DM320001) PIC32 General Purpose Starter Kit 32MX360F512L (DM320001)
80
PIC32 USB Starter Kit (DM320003_2) PIC32 USB (DM320003_2) PIC32 USB (DM320003_2) PIC32 USB (DM320003_2) PIC32 USB (DM320003_2) PIC32 Ethernet Starter Kit dsPIC33E USB Starter Kit dsPIC33E USB Starter Kit dsPIC33E USB Starter Kit dsPIC33E USB Starter Kit PIC24E USB Starter Kit PIC24E USB Starter Kit PIC24E USB Starter Kit PIC24E USB Starter Kit TCPIP WebVend ( Demo Board PICDEM.net 2 PICDEM.net 2 Explorer 16 Explorer 16 Explorer 16 Explorer 16 Explorer 16 Explorer 16 Explorer 16 Explorer 16 Explorer 16 Explorer 16 Explorer 16 Explorer 16 Explorer 16 Explorer 16 Explorer 16 TCPIP WiFi EasyConfig Demo App ( Demo Board Explorer 16 see page 123)
32MX795F512L 32MX795F512L 32MX795F512L 32MX795F512L 32MX795F512L 32MX795F512L 33EP512MU810 33EP512MU810 33EP512MU810 33EP512MU810 24EP512GU810 24EP512GU810 24EP512GU810 24EP512GU810
Internal MAC, National DP83848C PHY ENCX24J600 ENCX24J600 ENCX24J600 MRF24WB0M ENCX24J600 ENCX24J600 ENCX24J600 MRF24WB0M SPI2 PSP 5 PSP Indirect SPI2 SPI2 PSP5 PSP Indirect SPI2 5 5
Processor 18F97J60 18F97J60 24FJ128GA010 24FJ128GA010 24FJ128GA010 33FJ256GP710 33FJ256GP710 33FJ256GP710 32MX360F512L 32MX360F512L 32MX360F512L 32MX460F512L 32MX460F512L 32MX460F512L 32MX795F512L 32MX795F512L 32MX795F512L see page 130) Processor 24FJ128GA010
MAC/PHY Layer ENC28J60 ETH97J60 ENC28J60 ENCX24J600 MRF24WB0M ENC28J60 ENCX24J600 MRF24WB0M ENC28J60 ENCX24J600 MRF24WB0M ENC28J60 ENCX24J600 MRF24WB0M ENC28J60 ENCX24J600 MRF24WB0M
Comm. Bus SPI SPI SPI SPI SPI SPI SPI SPI SPI SPI SPI SPI SPI SPI SPI SPI
Notes
Notes
81
TCPIP WiFi Console Demo App ( Demo Board PICDEM.net 2 Explorer 16 Explorer 16 Explorer 16 Explorer 16 Explorer 16 PIC24FJ256DA210 Board
see page 124) Processor 18F97J60 24FJ128GA010 33FJ256GP710 32MX360F512L 32MX460F512L 32MX795F512L MAC/PHY Layer MRF24WB0M MRF24WB0M MRF24WB0M MRF24WB0M MRF24WB0M MRF24WB0M MRF24WB0M Comm. Bus SPI SPI SPI SPI SPI SPI SPI Notes
Development PIC24FJ256DA210
TCPIP Internet Radio App ( Demo Board Internet Radio Board TCPIP Internet Bootloader ( Demo Board N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A Processor 18F66J60 18F66J60 18F66J65 18F66J65 18F67J60 18F67J60 18F86J60 18F86J60 18F86J65 18F86J65 18F87J60 18F87J60 18F96J60 18F96J60 18F96J65 18F96J65 18F97J60
see page 123) Processor 18F67J60 see page 117) MAC/PHY Layer ETH97J60 ETH97J60 ETH97J60 ETH97J60 ETH97J60 ETH97J60 ETH97J60 ETH97J60 ETH97J60 ETH97J60 ETH97J60 ETH97J60 ETH97J60 ETH97J60 ETH97J60 ETH97J60 ETH97J60 Comm. Notes Bus Extended Instruction Mode Extended Instruction Mode Extended Instruction Mode Extended Instruction Mode Extended Instruction Mode Extended Instruction Mode Extended Instruction Mode Extended Instruction Mode MAC/PHY Layer ENC28J60 Comm. Bus SPI Notes
82
Demo App
N/A
ETH97J60
TCPIP MDD Demo App ( Demo Board Explorer 16 Explorer 16 Google Map
Processor
MAC/PHY Layer
Comm. Notes Bus SPI SPI Uses USB Thumb Drive as a storage medium for web pages. Uses SD Card as a storage medium for web pages.
For information on the Google Map demo compatibility, see the file "Getting Started - Running the Graphics Google Map Demo" in the Combo Demos/Google Map directory in your Microchip Applications Library installation directory.
Demo App
see page 94) see page 97) see page 98) see page 100)
Several custom modules are used in this demo. This section will describe the components and functionality of these modules.
HTTPPostDDNSConfig ( see page 90) HTTPPostEmail ( 91) HTTPPostLCD ( 91) HTTPPostMD5 ( 92) Variables Name DDNSData ( lastFailure ( lastSuccess ( see page 92) see page 93) see page 93) see page see page see page
Description RAM allocated for DDNS parameters Stick status message variable. See lastSuccess ( see page 93) for details. Sticky status message variable. This is used to indicated whether or not the previous POST operation was successful. The application uses these to store status messages when a POST operation redirects. This lets the application provide status messages after a redirect, when connection instance data has already been lost.
Description The CustomHTTPApp.c file demonstrates how to build a custom HTTP application on top of the HTTP2 server. All the features of the TCPIP Demo App web pages are implemented here. Examples can be found for handling Authentication ( see page 86), processing web forms (using HTTP GET and POST), and providing status information through the output of dynamic variables.
84
Demo App
3. Observe the current Stack Version and Build Date in the top center of the Overview Page. 4. Navigate to the Dynamic Variables page using the navigation panel on the left of the page. 5. Observe the Build Date and Time, LED state, stack version, and current IP address- these variables are output to this page dynamically when it's downloaded by the browser. Exercises You can optionally complete the exercises described on the Dynamic Variables page. You may want to read the HTTP2 dynamic variables topic ( see page 228) first. The first exercise is to implement the display of LED0 on the dynamic variable demo page. 1. Start by opening dynvars.htm in your "TCPIP Demo App\WebPages2" folder. 2. Locate the dynamic variables in the page and replace the question mark with a dynamic variable to display the value of LED 0. You can use the other LED variables as a template, but specify 0 as the LED to open.
3. In your MPLAB project, open CustomHTTPApp.c and ensure that the HTTPPrint_led function (if you used ~led(0)~ as your dynamic variable) if written to output data when 0 is passed in as a parameter. 4. Rebuild your web page with the MPFS2 Utility. 5. Rebuilt your project, and reprogram your board. Navigate to the dynamic variable page and verify that the LED0 field reflects the status of the LED on your board. Since the LED on your board is blinking, you may need to refresh the web page to view its current status. The second exercise on this page simply demonstrates how to dynamically insert a file into a web page. 1. Start by opening dynvars.htm in your "TCPIP Demo App\WebPages2" folder. 2. Locate the dynamic variables that include header.inc and footer.inc. Observe the difference between the declaration of these variables and the other variables on the page.
85
Demo App
7.2.1.2.1.2 Authentication
Module Web Page Demos ( Description Overview This section describes how to use the authentication demo in the TCP/IP Demo App HTTP2 demo. For information about how to implement authentication in your own page, see the HTTP2 Authentication topic ( see page 233). Instructions 1. Program your board with the demo code and upload the demo app web page. Open your web browser and navigate to the board's web page (http://mchpboard by default). 2. Navigate to the Authentication page using the navigation panel on the left of the page. 3. Note the authentication user name ("admin") and password ("microchip"). 4. Click on the "Access Restricted Page" link on the Authentication page. see page 84)
5. Enter an incorrect combination of usernames and passwords. The browser will not advance to the Access Restricted Page. After 3 incorrect username/password combinations, the browser will be redirected to an "Unauthorized" screen. 6. Click the back button in your browser. Click on the "Access Restricted Page" link and enter the correct username and password. 7. You will advance to the "Login Successful" page. Your browser will store this username/password combination until it is closed and reopened. Exercise You can optionally complete the exercise described on the "Login Successful" page. In this exercise, you will change the username and password that you use to log in to this page. 1. Open CustomHTTPApp.c in your TCP/IP Demo App MPLAB project. 2. Locate the HTTPCheckAuth ( see page 238) function.
3. Change the values being compared to the function inputs to a username and password of you choosing. 4. Rebuild your project and program your board.
Demo App
4. Select new LED states in the pull-down boxes. Click "Save" and observe that the LED states of your board changed to match the settings you selected.
Exercise You can optionally complete the exercise described on the "Form Processing" page. In this exercise, you will change the example to support LED5. You may want to read the HTTP2 form processing topic ( see page 230) first. 1. Start by opening forms.htm in your "TCPIP Demo App\WebPages2" folder. 2. Locate the GET method implementation the will display the LEDs. You should see select forms for the four LEDs that are already implemented. Each of these has two options: the On option will send a '1' to the server when submitted and the Off option will send a '0' when submitted. Each of the declarations of these options also use the ledSelected dynamic variable to determine which option will be selected by default, based on the current status of the corresponding LED on the board. This dynamic variable accepts two arguments: the first defines which LED is being checked, and the second describes the state being checked for. So, for example, the ~ledSelected(4,TRUE)~ variable will be replaced by the word "SELECTED" if LED4 is on when this variable callback function is called. In this case, ~ledSelected(4,FALSE)~ would be replaced by nothing. This would result in the 'On' option being selected by default in the page. 3. Create a new select input for LED5. 4. Open CustomHTTPApp.c in the TCP/IP Demo App MPLAB project. 5. Verify that the HTTPPrint_ledSelected dynamic variable callback function has been implemented for LED5. 6. Find the HTTPExecuteGet ( for the forms.htm file. see page 239) function. Locate the section of code the processes GET arguments
7. Add implementation to search for the "led5" argument string in the GET data buffer and then set LED5_IO based on the associated value.
4. Navigate to the File Uploads page using the navigation panel on the left of the page. 5. Browser for a file on your computer and click "Get MD5." The application will read your file using a series of POST transfers and calculate and display and MD5 hash of the contents.
6. Navigate to the Send E-mail page using the navigation panel on the left of the page. 87
Demo App
7. Fill in the form fields with the appropriate information. 1. No SSL - You will need a local SMTP server that does not require a secure connection. Enter the address in the SMTP Server field, set the port to 25, and enter your user name and password for the server. Set the "To:" field to the email recipient and press "Send Message." 2. SSL - Enter the address of a public SMTP server (e.g. smtp.gmail.com). Set the port number to 465 or 587. Enter your email account information (e.g. username@gmail.com and your Gmail password). Set the "To:" field to the email recipient and press "Send Message." Note that some corporate subnets may block outgoing secure traffic on the SMTP port. If this is the case, you'll have to establish a VPN tunnel outside this network or connect ( see page 168) your board to a network that's not blocked by this type of firewall. You must have installed the Microchip Data Encryption Libraries to use SSL, and SSL Client support must be enabled. See the SSL API ( see page 375) topic for more information.
8. Verify that the e-mail was received on the recipient e-mail address.
7.2.1.2.1.5 Cookies
Module Web Page Demos ( Description Overview This section describes how to use the cookie demo in the TCP/IP Demo App HTTP2 demo. For information about how to implement cookies in your own page, see the HTTP2 Cookies topic ( see page 235). Instructions 1. Program your board with the demo code and upload the demo app web page. Open your web browser and navigate to the board's web page (http://mchpboard by default). 2. Navigate to the Cookies page using the navigation panel on the left of the page. 3. Type your first name into the "First Name" text box and click "Set Cookies." Verify that the name was read successfully and displayed in the "Name" output field. see page 84)
Exercise You can optionally complete the exercise described on the "Cookies" page. In this exercise, you will create a cookie called "fav" with the value in the favorite field in the example box. You may want to read the HTTP2 dynamic variable ( see page 228), GET ( see page 230), and cookie ( see page 235) topics first. 88
Demo App
1. Start by opening cookies.htm in your "TCPIP Demo App\WebPages2" folder. 2. Locate the code for the example box that displays the name and favorite PIC architecture. Replace ( "not implemented" string with a dynamic variable to output the data from the cookie. see page 219) the
3. Locate the code for the select box form input for the favorite architecture. Note the value of the name field of the select form. 4. Open CustomHTTPApp.c in the TCP/IP Demo App MPLAB project. Locate the HTTPExecuteGet ( 239) function and find the code that handles GET method inputs from cookies.htm. 5. Set the value of curHTTP.hasArgs to indicate that two form arguments are present in the data buffer. 6. In CustomHTTPApp.c, create a function to output data for the dynamic variable you created in step 2. The name of the function will depend on the name of the variable. For a variable named ~cookiefavorite~ you would implement a function called HTTPPrint_cookiefavorite. This function should search through the curHTTP.data data buffer to try and find a name/value pair with the name equal to the name of your select form from step 3. If it finds it, it should write the value for that pair to the TCP buffer; otherwise, it should write "not set." See the implementation of HTTPPrint_cookiename for an example. void HTTPPrint_cookiename(void) { BYTE *ptr; ptr = HTTPGetROMArg(curHTTP.data, (ROM BYTE*)"name"); if(ptr) TCPPutString(sktHTTP, ptr); else TCPPutROMString(sktHTTP, (ROM BYTE*)"not set"); return; } 7. Compile your web page using the MPFS2 Utility and upload it to your board. You may receive a warning that your dynamic variables have changed in your page. 8. Rebuild your project and program your board. 9. Verify that both cookies can be set. see page
7.2.1.2.1.6 Functions
Functions Name HTTPPostSNMPCommunity ( see page 89) HTTPPostConfig ( page 90) see Description This is function HTTPPostSNMPCommunity. Processes the configuration form on config/index.htm Parsing and collecting http data received from http form. Processes the e-mail form on email/index.htm Processes the LCD form on forms.htm Processes the file upload form on upload.htm
HTTPPostDDNSConfig ( see page 90) HTTPPostEmail ( 91) HTTPPostLCD ( 91) HTTPPostMD5 ( 92) Module Web Page Demos ( see page 84) see page see page see page
89
Demo App
Microchip TCP/IP Stack Help Waiting for asynchronous process to complete, call again later
Demo App
91
Demo App
7.2.1.2.1.7 Variables
Module Web Page Demos ( Variables Name DDNSData ( lastFailure ( lastSuccess ( see page 92) see page 93) see page 93) Description RAM allocated for DDNS parameters Stick status message variable. See lastSuccess ( see page 93) for details. Sticky status message variable. This is used to indicated whether or not the previous POST operation was successful. The application uses these to store status messages when a POST operation redirects. This lets the application provide status messages after a redirect, when connection instance data has already been lost. see page 84)
92
Demo App
2. Replace ( see page 219) the initializer of the SMTPClient.Server.szROM structure element with the address of your mail server. Note that this demo does not include security features, so you will need a mail server that does not require SSL. To test this functionality with a mail server that does support SSL (including most public mail servers), please use the HTTPPostEmail ( see page 91) SMTP demo. 2. Compile the code, program your board, and run the demo. 3. Press buttons 2 and 3 on your board to transmit an email message. LED1 on your board will indicate that the message is being transmitted; LED2 will indicate that is was sent successfully. Check the BUTTON2_IO, BUTTON3_IO, LED1_IO, 93
Demo App
and LED2_IO macros in the copy of HardwareProfile.h that corresponds to your project to determine which buttons and LEDs are used for your hardware setup. 4. Verify that the message was received by the email account you specified in the RAMStringTo[] array. Description The short-message SMTPDemo ( see page 94) task function implements a four-state state machine. When the board is powered on, the state machine is initialized to the SM_HOME state, in which it waits for buttons 2 and 3 to be pressed. Once they are pressed, the task will enter the MAIL_BEGIN state. In the MAIL_BEGIN state, the task will attempt to requisition the SMTP module. Once it's able to do this, it will populate the SMTPClient ( see page 301) structure with message parameters and transmit the message. It will then enter the MAIL_SMTP_FINISHING state. In the MAIL_SMTP_FINISHING state, the task will check a callback function (SMTPIsBusy ( see page 302)) to determine when the module is finished. It will then give up control of the SMTP module and toggle LEDs based on the successful operation of the SMTP module. The state machine will then enter the MAIL_DONE state, which will wait at least 1 second before transitioning back to MAIL_HOME, allowing another email to be sent.
94
7.2 Available Demos Variables Name RemoteURL ( ServerName ( ServerPort ( Description Overview
Demo App
Description see page 96) Defines the URL to be requested by this HTTP client see page 96) Defines the server to be accessed for this application see page 96) Note that if HTTPS is used, the ServerName ( change to an SSL enabled server. see page 96) and URL must
The Generic TCP Client provides an example of how to build an HTTP client (or any other TCP client) using the Microchip TCP/IP Stack. It will print out the results from a search engine query to the PIC's UART module. The result data can be viewed on a PC terminal. Instructions 1. Connect the programmed demo board to a router that is connected to the Internet. 2. Connect your PC to your demo board with an RS-232 cable. Open a terminal program like HyperTerminal, and configure it to the following settings: 19200 bps, 8 data bits, No parity, 1 stop bit, No flow control. 3. Press Button 1 on your demo board (check the BUTTON1_IO macro in the copy of HardwareProfile.h that corresponds to your project to determine which button is Button 1). 4. Observe the search results for "Microchip" at www.microchip.com on your terminal. Description The Generic TCP Client demo implements a task function with five states. When the board is powered on, the initial state will be set to SM_DONE. This state will wait for the user to press Button 1; when a button-press event occurs, the state will switch to SM_HOME. In the SM_HOME state, the task will attempt to open a TCP client socket ( see page 149). This socket will use a TCP_PURPOSE_GENERIC_TCP_CLIENT socket type ( see page 149) from the TCP socket structure ( see page 150) that was initialized in your configuration files. The targeted server will be the Google search engine, and the server port will be 80, the port used for HTTP connections. The task will switch the state machine to the SM_SOCKET_OBTAINED state. The task will wait in the SM_SOCKET_OBTAINED state until a connection is established with Google or a 5-second timeout elapses. If a timeout occurs, the state will close the socket and change the state back to SM_HOME. Otherwise, it will wait until the TCP buffer can accept ( see page 166) 125 bytes of data and then use an HTTP GET ( see page 230) to search for the word "Microchip" at the site "microchip.com." Once the GET has been sent, the state will switch to SM_PROCESS_RESPONSE. In the SM_PROCESS_RESPONSE state, the task will wait until a response is received or the socket was disconnected. If a response is received, it will print it to the UART. In either case, the task will transition to the SM_DISCONNECT state, where it will close the client socket and return to the SM_DONE state.
95
Demo App
This function implements a simple HTTP client, which operates over TCP. The function is called periodically by the stack, and waits for BUTTON1 to be pressed. When the button is pressed, the application opens a TCP connection to an Internet search engine, performs a search for the word "Microchip" on "microchip.com", and prints the resulting HTML page to the UART. This example can be used as a model for many TCP and HTTP client applications. Preconditions TCP is initialized.
7.2.1.2.3.2 Variables
Module Generic TCP Client ( Variables Name RemoteURL ( ServerName ( ServerPort ( Description see page 96) Defines the URL to be requested by this HTTP client see page 96) Defines the server to be accessed for this application see page 96) Note that if HTTPS is used, the ServerName ( change to an SSL enabled server. see page 96) and URL must see page 94)
96
Demo App
97
Demo App
7.2.1.2.4.2 Macros
Macros Name SERVER_PORT ( page 98) Module Generic TCP Server ( see page 97) see Description Defines which port the server will listen ( see page 172) on
Demo App
The Ping Demo explains how to use the ICMP client to check if a remote node is reachable. If the project with this demo includes the DNS module, the PIC will ping "ww1.microchip.com." Otherwise, it will ping the local gateway. This demo is only available on hardware setups with LCD displays (e.g. Explorer 16 or PICDEM.net 2). Instructions 1. Press Button 0 on your demo board. Button 0 is usually the rightmost or topmost button on the board (check the BUTTON0_IO macro in the copy of HardwareProfile.h that corresponds to your project to determine exactly which button is Button 0). 2. When the device receives an echo response from the remote node or when the ping times out, the LCD will be updated with the appropriate information. Description The PingDemo ( see page 99) task function implements a two-state state machine. The task will wait in the SM_HOME state until the user presses button 0. Once the button is pressed, the task will attempt to obtain ownership of the ICMP module with the ICMPBeginUsage ( see page 261) function. If it does, it will send a ping to the specified address and transition to the SM_GET_ICMP_RESPONSE state. In the SM_GET_ICMP_RESPONSE state, the task will call the ICMPGetReply ( action depending on the return value: Value Action -2 -1 -3 Remain in this state and keep waiting for a response. Write a message to the LCD indicating that the ping timed out. Change state to SM_HOME. Write a message to the LCD indicating that the DNS module couldn't resolve the target address. Change state to SM_HOME. see page 263) callback function and take
Other Convert the response time to a text string and print it to the LCD. Change state to SM_HOME.
99
Demo App
7.2.1.2.5.2 Macros
Macros Name HOST_TO_PING ( page 100) Module Ping (ICMP) Demo ( see page 98) see Description Address ( see page 144) that ICMP client will ping. If the DNS client module is not available in the stack, then this hostname is ignored and the local gateway IP address will be pinged instead.
Description
MAX_TRY_TO_SEND_TRAP ( see page 115) SNMP_MAX_NON_REC_ID_OID Update the Non record id OID value which is part of CustomSnmpDemo.c ( see page 115) file STACK_USE_SMIV2 ( page 115) Variables Name gSendTrapSMstate ( page 114) see Description This is variable gSendTrapSMstate. OLD snmp.mib file with SMIv1 standard This is variable gSnmpv3UserSecurityName. see Default STACK_USE_SMIV2 is enabled . For Stack V5.31, STACK_USE_SMIV2 should be disabled.
The Microchip SNMP server is a multilingual implementation which supports SNMPv1, V2c and V3 server features simultaneously. SNMP server is implemented to address the requirements of embedded applications. The SNMPv3 support 100
Demo App
is added with TCPIP Stack Version 5.31. SNMPv1 and V2c are enabled with single macro #define STACK_USE_SNMP_SERVER. The SNMPv3 server could be selectively enabled with independent macro #define STACK_USE_SNMPV3_SERVER. As SNMPv3 stacks are required to support SNMPv1 and SNMPv2c, enabling the SNMPv3 Server will automatically enable SNMPv1 and SNMPv2c servers in the Microchip TCPIP Stack SNMP agent. These macros are defined in the TCPIP (MAC/PHY).h file located at <Installation Path>:\Microchip Solutions MAIN\TCPIP\Demo App\Configs\. This series of topics will address the application- and demo-specific implementation of an SNMP server included with the TCP/IP Demo applications. For information describing the SNMP module in general, please see the SNMP API topic. V2c is implemented with support for the configuration of multiple community names, which are stored in selected non-volatile memory (SPI EEPROM or SPI Flash). The community names can be configured through the TCP/IP Configuration Wizard or through the HTTP/MPFS2 web interface. An access-restricted web page is provided with the demo application to allow dynamic configuration of SNMP communities. SNMPv3 RFC specifies different types of access mechanism, user security model (USM), authentication and privacy protocols. Microchip SNMPv3 server is implemented with support for USM, AES 128 CFB 128 privacy protocol, and MD5 and SHA1 message authentication protocols. The demo implementation of the server is configured with 3 different types of user names with respective authentication and privacy credentials and authentication types. These credentials and other user information are stored in the global array. The user of the SNMPv3 stack can decide on the number of user names in the Users data base to be stored with the Server. According to the SNMPv3 recommendation, SNMPv3 server should not be configured with the authentication and privacy passwords. Instead could be configured with the respective localized keys of the password. Microchip SNMPv3 agent is provided with the password information in the database for the Getting Started and for understanding purpose only. It is recommended that the SNMPv3 stack should be modified to restrict access to the password OIDs declared in the user data base. Note that even though SNMPv3 also requires SNMPv1 and SNMPv2c, a layer in the SNMP stack will prevent access to the variables that should be secured by SNMPv3. SNMP variables are structures in a tree in the Management Information Base (MIB). Access to parts of this tree are determined by version. For example, SYSTEM-type variables can be accessed regardless of SNMP version, SNMPv2c requests can access part of the tree, and authenticated SNMPv3 requests can access the complete tree. You will require two firmware packages to run the SNMPv3 server demo. Each of these must be installed in the order listed, as some files will be overwritten. The software encryption library is not required if the SNMPv3 services are not intended.
1. The Microchip Application Libraries, including TCP/IP Stack v5.31 or later. This code is available at www.microchip.com/mal. 2. Microchip's Data Encryption Libraries. This demo uses the SSL security layer to communicate with Google. To use SSL with the TCP/IP stack, you will require these libraries. They are available in a CD-based or downloadable format from MicrochipDirect for a small fee (required to comply with U.S. cryptographic export restriction screening). You must execute the "Microchip TCPIP Stack vX.XX Encryption Add-on.exe" installer to install the files required by the demo. The ARCFOUR.c/h and RSA.c/h cryptographic files in this installer will replace the dummy versions found with the default TCP/IP Stack installation. To enable SNMPv3 functionality, you must add the PIC32_AES.a library from the Data Encryption Libraries to your demo project.
Note: For existing Microchip SNMP V1 and V2c users. SNMP V1/V2c users wanting to upgrade the Microchip TCP/IP Stack from older versions to the latest version and continue to use SNMP V1/V2c can get the SNMP V1/V2c services from this agent, provided they do not modify the default settings of the SNMP module in v5.25 onward. The implementation framework for V1 and V2c remains the same, except for a few new features and functions. The names and parameters of some of the functions have been changed. V1/V2c users may have to make changes to their application-specific code. There should not be any change in the SNMP stack code unless users have incorporated application code in the SNMP stack.
101
Demo App
Users should build a new MPFS image using the MPFS File System Generator utility and upload it to the selected EEPROM or Flash memory, as the AppConfig structure is updated to accommodate community names in V2c and SNMP engine ID for SNMPv3.
The minimum set of RFC 1213 MIB2 variables that are required to identify the Microchip node as an SNMP node to the network are implemented. These variables can be accessed by any SNMP browser with a "public" type community name. 102
Demo App
Refer to AN870 - "SNMP V2c Agent for Microchip TCP/IP Stack" for more details on the MIB scripts, community names, and demo SNMP MIB variable tree structure. The following figure shows the variables implemented in the Microchip SNMP Agent.
The ASN.1 format mchip.mib file is defined with a private variable tree structure for the MIB variables. Also the mchp.mib is added with number of OIDs which could be accessed only with SNMPv3 request. The browser can access every variable in the MIB database provided the community name matches. The access to the MIB variables is restricted to the type of the request. The RFC1213 mib variables could be accessed with SNMPv2c/v3 request. But the SNMP-FRAMEWORK-MIB.mib variables could only be accessed with SNMPv3 reqeust if the credentials are matched and the message is authenticated. To modify these MIB variables, corresponding changes must be made to both MIB scripts (snmp.mib and mchip.mib). The following figure shows the Microchip private MIB variable tree structure in the browser.
Configuring the Browser To configure the iReasoning MIB browser: 1. Select the "Advanced" tab in the browser.
103
Demo App
2. If V2C services are required, select SNMP version V2c, configure the Read and Write community to the browser. The V2c agent will respond only to the queries from SNMP MIB browsers using the same community. That is, the V2c agent and the browser should be members of the same community. If the community fields are left blank, the manager sends the SNMP request with the community name as "public." The V2c agent is configured by default with 3 Read communities ("public", "read", "") and 3 Write communities ("private","write","public"). The default maximum community length is 8 characters. As the default communities also contain the "public" community name, the agent will respond to all of the browsers requesting the "public" community. The TCP/IP Configuration Wizard ( see page 59) can be used to configure the default SNMP community names. At run time, the community names can be dynamically configured using the HTTP interface for SNMP community name configuration. If the V2c agent receives an SNMP request with an unknown community name, the agent will generate an Authentication ( see page 86) trap. The V2c agent's multiple community support feature enables the user application to provide limited access to the requesting browser based on the community name used by the browser to access the MIB database variables of the agent. 3. If SNMPv3 services are required, select the SNMP Version as 'V3' in the 'Advanced' tab of the SNMP MIB Browser. The following configuration window will be displayed:
4. If SNMPv3 services are required, SNMPv3 browser is required to be configured with the user name, authentication and privacy password, message authentication hash type, privacy protocol type. The SNMP server would respond only if one of the user credentials and user security parameters in the below table is configured at the manager. The below table is stored in the global structure with the SNMPv3 server stack. The SNMPv3 server would only respond if the request credentials of the MIB browser matches to that of the stored user data base of the SNMP server.
104
Demo App
USER 1 USM User Security Level Auth Algorithm Auth password Privacy Algorithm Privacy password microchip auth, priv MD5 auth12345 AES priv12345
5. The Microchip SNMPv3 stack does support only one Context Engine ID with the server. Leave the "Context Name" option in the "Advanced" tab empty. It is ignored on the server. 6. According to the user and the auth and privacy protocols configured with the SNMP browser, the UDP authenticated and encrypted message would be exchanged between server and the client. If the USER 1 values, as in above table, are configured in the MIB browser, the data exchange between client and server is encrypted and authenticated. The PDU could be captured in the Ethernet packet sniffer like WireShark and examined. As the data is encrypted and authenticated, the data integrity and the privacy is achieved. If USER 2 values, as in above table, are configured in the MIB browser, the data exchange between client and server is authenticated. The data integrity would be checked once the data is received at either end. The message authentication mechanism protects from the possible data sniffing and modification threat, and alos guarantees that the data is received from the authenticated and guaranteed source. if USER3 values, as in above table, are configured in the MIB browser, the data exchange between client and server is neither authenticated nor encrypted. Considering the above three USER configurations, if the SNMP server is to be accessed over WAN, in the internet cloud, tha data should be encrypted and authenticated to have the highest level of data privacy and integrity. 7. Configure the IP address of the SNMP agent to the "Address ( see page 144) field.
7. Select the variable to be accessed from the agent MIB database from the SNMP MIBs pane. The selected variable's OID can be seen in the OID tab in the following figure.
9. The SNMPv3 server demo MIB is included with RFC1213 SNMPv2 MIB variables, private mib variables and the SNMP-FRAMEWORK-MIB variables. If the SNMPv2C request with validated community name is generated from the MIB Browser, only set of few variables is accessed. The access to the MIB variables is restricted to the type of SNMP version request received. If the SNMPv3 request with correct credentials is generated from the MIB Browser, the complete MIB access is provided. 10. The user would require to decide on which part of the MIB should be required to be restricted depending upon the 105
Demo App
SNMP version type. The MIB design is the one of the important step in deciding the MIB tree structure and the variable to be placed accordingly. 11. The SNMP server demo MIB is added with a static variable OID named as "snmpv3PvtObject" with OID value as 43.6.1.4.1.17095.6.1. This variable is placed in the private branch of the MIB by creating an independent branch. All the other variables in the private branch are accessible by SNMPv2c request. The access to this static variable is restricted by the SNMP version type. Only the SNMPv3 request with correct credentials could access this variable. Exploring the Demo After the MIB script is uploaded to the SNMP browser, the MIB tree structure will be displayed in the browser. Any of the variables in this tree can be accessed (using SNMP operations) from the agent if the agent supports these variables. The browser and agent should be members of the same community. To learn more about SNMP operations, PDU types, and terminology, refer to AN870 - "SNMP V2C Agent for Microchip TCP/IP Stack."
As explained earlier, the V2c agent is configured with three Read and Write community defaults. Configure the browser to use any of these communities and try accessing the MIB variables. You should be able to access some of the MIB variables even with the Read Community configured as any of the 'write' community defaults. For GET operations, if the Read or Write community matches, the agent processes the request. For SET operations, the received community names must match any of the 'write' community names. For SNMP V3, substitute '3' in place of '1' in the version configuration in the "Advanced" tab. Configure the other user based auth and priv credentials as explained in the "MIB Browsers" section. With appropriate credentials, all the MIB variables are accessible. Select any of the MIB variables in the MIB tree and do a GET operation.
Get_Next 1. Repeat the process for GET. Select the sysDescr variable from the MIB tree. Select "Get Next" from the operations menu. The result table will display the sysObjectID variable information. 2. Repeat for additional MIB variables to get the information for the corresponding next variable.
106
Demo App
3. Set the SNMP MIB Browser version to v1/v2c. Try to access the private MIB variable "snmpv3PvtObject" with OID value as 43.6.1.4.1.17095.6.1. The access should be restricted. Set the verison to V3, configre the credentails, again try a Get_Next operation for the sae variable. The access should be granted. Get_Bulk This operation is supported in SNMP V2c and SNMP V3. Get_Bulk enables the collection of bulk information from the agent with a single request from the manager. 1. Configure the SNMP version to '2' or '3' in the SNMP browser. 2. If version is configured to '2', set the Read Community to 'public' or 'read.' 3. If version is configured to '3', configure the appropriate V3 credentials. 4. Select the sysDescr variable from the MIB tree. 5. Select the Get Bulk operation from the Operations menu. The result table will display information for 10 MIB variables in a single request (if the Max-Repetitions=10 and Non-Repeaters=0 is configured). These variables are the lexicographical successors of the sysDescr variable. The number of variables that the agent will respond with can be configured in the browser through the menus: "Tools->Options->Non-Repeaters" and "Tools->Options->Max-Repetitions." The Non-Repeaters and Max-Repetitions numbers are extracted by the SNMP agent from the received Get_Bulk request and the number of variables that will be included in the response PDU is calculated. for more information on calculating the number of variables, Non-Repeaters, and Max-Repetitions, refer to RFC 3416.
Set The Set command updates the variable information of the MIB database in the agent. The Set command can be performed only on those variables which are declared as 'READWRITE' in the MIB scripts, and only if the community name matches any one of the 'write' community names configured with the agent. 1. Select the ledD5 variable from the MIB tree. 2. Configure the SNMP version to '1' or '2.' Configure the Write Community to 'public', 'write', or 'private'. 3. If version is configured to '3', configure the appropriate V3 credentials. 4. Select 'Set' from the Operations menu.
The SNMP SET window will pop up. Enter the value for the browser in the OID field.
107
Demo App
A 'Get' operation for the same variable should now return the new 'Set' value for this variable. LED5 on the demo board should now be ON. Repeat the procedure to set LED5 to OFF. LED6 can also be set ON or OFF.
108
Demo App
Comment out the #define SNMP_TRAP_DISABLED macro Uncomment the #define SNMP_STACK_USE_V2_TRAP macro
Comment out the #define SNMP_TRAP_DISABLED macro Uncomment the #define SNMP_V1_V2_TRAP_WITH_SNMPV3 macro Uncomment the #define SNMP_STACK_USE_V2_TRAP macro
Demos Two trap demos are included with the TCP/IP Stack. The task functions for these demos are called in the main application function: SNMPTrapDemo() - This API demonstrates V1 or V2 trap formats (depending of the status of the SNMP_STACK_USE_V2_TRAP macro). The trap PDU will only have one demo variable binding on the varbind list. SNMPV2TrapDemo() - This API provides V2 format notifications with multiple (3) variable bindings. The user should modify or use this routine as a reference for sending V2 trap format notifications with multiple bindings on the varbind list. The user should only enable one SNMP demo API at a time. By default, the SNMPTrapDemo() API is enabled and SNMPV2TrapDemo() is commented out. V1/V2 Formatted Traps with a Single Variable Binding In the TCPIPConfig.h header file: Uncomment #define SNMP_TRAP_DISABLED Comment //#define SNMP_STACK_USE_V2_TRAP For the Trap demonstration, two events are defined within the V2c agent: If the Analog Potentiometer value is greater than 512, the agent will send a Trap every 5 seconds to the configured 'trapReceiverIPAddress.' If Button 3 on the demo board is pressed, an organization-specific PUSH_BUTTON trap will be sent. The current implementation of the V2c agent also generates a standard "Authentication ( If a request is received to modify (Set) a private MIB variable, or If the value of the variable is requested (get) by a browser with the wrong community name. Procedure: 1. Open the "Advanced" configuration menu, configure the SNMP version to '2,' and configure the Write Community to "public', 'write', or 'private'. 2. Select the 'trapEnabled.0' variable from the MIB tree. 3. Select 'Set' from the Operations menu. 4. Enter '1' in the value field of the SNMP SET window. 5. Select 'trapReceiverIPAddress.0' from the MIB tree. 6. Set the value to the IP address of the PC on which the SNMP browser is installed and running. 7. Select 'trapCommunity.0' from the MIB tree. 8. Set the community name of the SNMP browser (the default community, if not set, is 'public'). The 'trapCommunity' name will work as a filter for the SNMP browsers on a trap-monitoring server. 9. Open the "Trap Receiver' utility that was installed with the iReasoning MIB browser (Start->Programs->iReasoning->MIB Browser->Trap Receiver). see page 86) Failure Trap":
109
Demo App
To test the analog potentiometer trap, adjust the potentiometer on the demo board so the value is greater than 512 (turn it clockwise). This is an enterprise-specific trap. The SNMP Manager will receive the source IP address, the OID (as the name of the variable), the value, the timestamp, etc. for each event. The browser will interpret the data as AnalogPot variable information based on the OID name.
To test the push button trap, press the appropriate button on the development board (RB0 on the PICDEM.net 2 or S3 on the Explorer 16 board). To test the Authentication ( see page 86) Failure trap, configure the Read Community in your browser to a community name that is not supported by the agent (the default supported names are 'public' and 'read'). For example: 1. Configure 'mchp' as the Read Community name in the browser. 2. Select the private MIB variable LED5 from the MIB tree and issue a 'Get' operation from the browser. The result table of the browser won't display any result, but the Trap Receiver will receive and Authentication ( 86) Failure trap. see page
This is an intimation from the agent to the SNMP Manager that there was an unauthorized attempt to access the private MIB variable in the database. V2 Formatted Traps with a Multiple Variable Bindings In the TCPIPConfig.h header file: 110
Demo App
Uncomment #define SNMP_TRAP_DISABLED Uncomment #define SNMP_STACK_USE_V2_TRAP The SNMP V2 Trap PDU structure is: Version (2) | community | SNMP-PDU pdu-type (TRAP=0xA7) | request-id | error-status | err-index | varbind List The first two variable varbinds in the variable binding list of an SNMPv2-TRAP-PDU are sysUpTime.0 and snmpTrapOID.0, respectively. If any additional variables are to be included, then each of these varbind structures must be copied to the variable binding list. For the SNMPv2 multiple TRAP variable varbind demonstration, ANALOG_POT0 is used to generate an event and transmit an SNMP v2 Trap PDU. Adjust the analog potentiometer to a value greater than 512 (turn it clockwise) on the demo board. In addition to the sysUpTime.0 and snmpTrapOID.0 varbinds, the additional varbinds that are included with the trap PDU are: PUSH-BUTTON LED0_IO ANALOG_POT0 The following figure shows a V2 formatted trap with ANALOG_POT0 as the variable binding to be notified.
The next figure shows a multiple-variable varbind for an SNMP V2 Trap PDU, with the three additional variable bindings:
111
Demo App
112
Demo App
7.2.1.2.6.6 Functions
Functions Name SendNotification ( 113) Description see page Prepare, validate remote node which will receive trap and send trap pdu. see Obtains the current Tick value for the SNMP time stamp.
113
Demo App
This function retrieves the absolute time measurements for SNMP time stamp.Use TickGet ( TickGetDiv64K ( see page 517) to collect all 48bits of the internal Tick Timer. Remarks None. Preconditions None Return Values Return Values timeStamp Description DWORD timevalue
7.2.1.2.6.7 Variables
Module SNMP Server (Agent) ( Variables Name gSendTrapSMstate ( page 114) see Description This is variable gSendTrapSMstate. OLD snmp.mib file with SMIv1 standard This is variable gSnmpv3UserSecurityName. see page 100)
114
Demo App
7.2.1.2.6.8 Macros
Macros Name MAX_TRY_TO_SEND_TRAP ( see page 115) SNMP_MAX_NON_REC_ID_OID Update the Non record id OID value which is part of CustomSnmpDemo.c ( see page 115) file STACK_USE_SMIV2 ( page 115) Module SNMP Server (Agent) ( see page 100) see Default STACK_USE_SMIV2 is enabled . For Stack V5.31, STACK_USE_SMIV2 should be disabled. Description
************************************************************************ This Macro is used to provide maximum try for a failure Trap server address
Demo App
6. As you type characters in the command prompt, they will be transmitted over the Telnet ( see page 485) TCP port to the PIC, and then transmitted out of the PIC's UART to appear on your terminal program. As you type characters in the terminal program, they will be transmitted to the PIC through the UART module, and then retransmitted over the TCP connection to appear in the command prompt Telnet ( see page 485) session.
Internet Bootloader
Currently, the use of Zeroconf is limited to the WiFi demo applications (and the MRF24WB0M module). Future versions of the stack should enable Zeroconf support across all Ethernet solutions. Link Local The first component of Zeroconf is the ability to self-assign an IP address to each member of a network. Normally, a DHCP server would handle such situations. However, in cases where no DHCP server exists, Zeroconf enabled devices negotiate unique IP addresses amongst themselves. mDNS The second component of Zeroconf is the ability to self-assign human-readable hostnames for themselves. Multicast DNS provides a local network the ability to have the features of a DNS server. Users can use easily remembered hostnames to accesses the devices on the network. In the event that devices elect to use the same hostname, as in the IP address resolution, each of the devices will auto-negotiate new names for themselves (usually by appending a number to the end of the name). Service Discovery The last component of Zeroconf is service discovery. All Zeroconf devices can broadcast what services they provide. For instance, a printer can broadcast that it has printing services available. A thermostat can broadcast that it has an HVAC control service. Other interested parties on the network who are looking for certain services can then see a list of devices that have the capability of providing the service, and connect ( see page 168) directly to it. This further eliminates the need to know whether something exists on a network (and what it's IP or hostname is). As an end-user, all you would need to do is query the network if a certain service exists, and easily connect ( see page 168) to it. Demo The demo, when enabled, shows all three items above working together. Each development kit in the network assumes the hostname of MCHPBOARD-x.local, where x is an incrementing number from 1 (only in the case where multiple kits are programmed for the network). Each board will broadcast it's service, which is the DemoWebServer. Zeroconf Enabled Environments All Apple products have Zeroconf enabled by default. On Windows, you'll need to download the Safari web browser, and during the install, enable support for Bonjour. Note that in the Safari browser, you can browse and see a list of all Bonjour enabled devices, and click through to them automatically.
117
Internet Bootloader
Requires 0B of RAM (all used RAM is overlaid with main application) Requires no CPU time while executing main application Requires minimal or no changes to main application code and linker script Does not interfere with application interrupt vector locations or add interrupt latency Can reprogram configuration words Can reuse MAC and IP address provided by main application Client update software is already available on most computers
118
Internet Bootloader
Memory Map The entire program memory map when using the bootloader is shown below.
*: GOTO instruction is automatically generated by bootloader when writing. Application instruction at address 000000h is moved to Bootloader Jump Table. **: Some configuration options are not supported and will automatically be changed by the bootloader before flashing. The bootloader requires HS or HS+PLL oscillator mode and does not support 1:1 and 1:2 Watchdog Timer Postscale modes. Switching between Extended and non-Extended mode is not supported either. (The bootloader must be recompiled to change modes.) The bootloader uses a block of 8256 bytes of program memory. To prevent the application from inadvertently using this block, you should modify the linker script in your application prior to compiling. For example, for the MPLAB C18 C compiler, the linker script will contain a CODEPAGE line describing the available Flash memory in the device. For the PIC18F97J60 product with 128kB of program memory, the linker script (18f97j60i.lkr) will contain a line such as: CODEPAGE NAME=page START=0x2A END=0x1FFF7 This line indicates that the linker can place application constants and code anywhere between 00002Ah and 01FFF7h. This line must be split into two CODEPAGE lines to describe the gap in available program memory occupied by the bootloader. Ex: CODEPAGE NAME=page START=0x2A END=0x1DBBF CODEPAGE NAME=page2 START=0x1FC00 END=0x1FFF7 The above example removes the Jump Table and Bootloader Code blocks for the PIC18F97J60 with 128kB of Flash memory. Other devices with less Flash memory will need to use different start and end values according to the Jump Table start address and Bootloader Code end address described in the memory map figure above. 119
Internet Bootloader
Erase Operations The TFTP server performs a "bulk erase" before starting any TFTP put (write) operation. The erase is not a true bulk erase because the bootloader and configuration words remain intact. However, all other locations are reverted to their unprogrammed state. The erase procedure starts with the Flash page containing the Jump Table and continues backwards in memory towards address 000000h. After address 000000h is erased, the last program memory page containing the device configuration words is erased. For example, assuming a PIC18F97J60 with 128kB of Flash, the erase procedure will follow these steps: 1. Erase 01D800h-01DBFFh 2. Erase 01D400h-01D7FFh 3. Erase 01D000h-01D3FFh 4. ... 5. Erase 000400h-0007FFh 6. Erase 000000h-0003FFh 7. Erase 01FC00h-01FFFFh After the last page containing the configuration words are erased, the configuration words are immediately reprogrammed to their previous value. This algorithm provides very robust operation with an extremely low likelihood of destroying access to the bootloader due to an unexpected event (ex: power or network connectivity is lost while bootloading). Unexpected events will leave the first GOTO instruction at address 000000h intact, ensuring that the bootloader will start up again. Because the configuration words are erased last, there will not be any means of circumventing the internal code protect feature while application code still remains in the device. Program Operations Program operations are performed sequentially starting at address 000000h and growing upwards, as presented in the .hex file to be programmed. The device configuration words are typically the last values encountered in the .hex file. Because the erase procedure involves clearing the configuration words and then immediately reprogramming them, the configuration words will already be programmed by the time the configuration words are encountered in the .hex file. Therefore, if the .hex file contains different configuration words from what are already stored in the Flash memory, the bootloader will have to perform a new erase operation on the last page prior to programming the new configuration words. This extra erase/write cycle will reduce overall Flash endurance on the last page as compared to the rest of the device. However, the bootloader will not perform this erase/write if the configuration words have not changed. This feature preserves endurance for most application firmware upgrades, which typically do not require different configuration options to be programmed. Read Operations To save code space, the bootloader currently only supports reading through the TFTP server as binary data. Instead of getting a .hex file from a TFTP get operation, the bootloader will send back a binary file sized to the amount of internal Flash memory available (128kB for PIC18F97J60, 64kB for PIC18F66J60, etc.). The bootloader verifies code immediately after programming devices, so the read feature is primarily for debugging only. Read operations are disabled if the currently programmed application has the PIC microcontroller Code Protect feature turned on.
MAC Address (
120
Internet Bootloader
These default addresses are statically defined and can only be changed by recompiling the bootloader itself. However, if the bootloader is called from the main application, such as with the Reboot ( see page 314) module, then the bootloader will use the application assigned IP and MAC addresses (if provided). The only services that are available during bootloader operation are TFTP and ARP. ICMP (ping) and other services are not implemented. Configuring Your PC (Power-on Reset entry) To access the bootloader, the bootloader's IP address must be on the same subnet as your computer. For the default 192.168.97.60 IP address, you must temporarily change the settings on your PC. If the bootloader's IP address was application specified and already on the same subnet as your PC, then this section should be skipped. The following instructions assume you are using Microsoft Windows XP and will vary for other operating systems.
1. Open Network Connections. 2. Right click on the network adapter that you are using to communicate with the bootloader and choose Properties.
Internet Bootloader
4. Select Use the following IP address and then enter the IP address 192.168.97.61.
5. Click OK and then Close on the previous dialog to close them and set the new address. TFTP Operation (Power-on Reset entry) Most operating systems come with a TFTP client built in. In Microsoft Windows, this utility is named tftp.exe. This utility is a very simple console application which can be used to upload your application .hex file over the network to the bootloader. To perform a Flash upgrade using the tftp.exe client, follow these procedures: 1. At a console, type the following command, but do not execute it. Make appropriate path changes to the .hex file. tftp 192.168.97.60 put "C:\Microchip Solutions\TCPIP Demo App\TCPIP Demo App-C18.hex" 2. Power cycle the target board or if the device has a MCLR reset button, press it. 3. Quickly press enter to execute the tftp command. If firmware is already in the device, the bootloader will automatically terminate after approximately 4 seconds, so you must execute the tftp command within the 4 second window. 4. If successful, the TFTP client will indicate how long the transfer took. Actual programming time will vary based on numerous factors, including need to erase the Flash first, .hex file size, .hex file complexity, and internal programming time. The reported transfer rate is therefore not a good metric of network performance in embedded applications.
The bootloader does data read back verification shortly after writing and does not need a second step to read back the Flash contents. If a verification error occurs, the error will be immediately reported to the TFTP client.
The most likely cause of a verification failure is not a Flash endurance problem, but rather, an invalid .hex file given as input. As shown in the bootloader memory map, .hex files cannot contain any data within the 8KB area of Flash were the bootloader is stored. The bootloader internally masks off this region of Flash and treats it as read only to prevent bootloader corruption. As a result, if the .hex file contains data in the read-only region, the write will fail and verification will show a mismatch. 5. After a successful write, the bootloader will time out after approximately 4 seconds and begin executing the main application that was just loaded. After completing the TFTP upload process, restore your PC's IP address settings to allow normal network activity and access to the application you bootloaded. TFTP Operation (Application entry)
122
Internet Radio
If using an application which auto-detects TFTP packets and enters the bootloader as needed, such as the Reboot ( see page 314) module in the Microchip TCP/IP Stack, then there will generally be no need to reconfigure your PC or go through a time-sensitive power cycling process. Instead, you can execute a TFTP operation directly on the device without any interactive steps. 1. At a console, type the following command and execute it. Make appropriate IP adddress/hostname and path changes. tftp mchpboard put "C:\Microchip Solutions\TCPIP Demo App\TCPIP Demo App-C18.hex" If the bootload process is interrupted due to a network failure or user cancellation, you can simply retry the tftp command. The bootloader will not attempt to run a partially bootloaded application. The application specified MAC and IP address will be retained indefinitely until the device is power cycled or otherwise reset. If the bootload operation is interrupted due to a power failure, the bootloader will start back up using the Power-on Reset default MAC and IP addresses. In this case, you must follow the Power-on Reset entry directions to recover.
7.2.3 WebVend
The TCPIP WebVend App is a sample web-enabled vending machine application. It is used by the TCP/IP Webinar series: 1. TCP/IP Networking Part 1: Web-Based Status Monitoring (view) 2. TCP/IP Networking Part 2: Web-Based Control (view) 3. TCP/IP Networking Part 3: Advanced Web-Based Control (view)
123
WiFi Console
help Lists all the available CLI commands for the MRF24WB0M. getwfver Lists the WiFi firmware and host driver version numbers.
124
WiFi Console
reset Issues a host reset. cls Resets the prompt. kill iperf Kills a running iperf session. See the section on iperf ( see page 128) for more information.
iwconfig commands take the following structure: iwconfig [ [ [ [ [ [ [ [ [ [ ssid <name> ] mode <idle|managed|adhoc> ] channel <channel list|all> ] power <reenable|disable|unicast|all> ] domain <name> ] rts <length> ] txrate <0|1|2> ] scan ] hibernate ] wakeup ]
Note: iwconfig with no options will display wireless status. ssid name 1-32 ASCII characters. Currently doesn't accept ( mode idle managed adhoc Forces the MRF24WB0M to disconnect from any currently connected network (adhoc or infrastructure). The MRF24WB0M will connect ( see page 168) to the SSID in infrastructure mode. Note that all the network parameters must be correct before this command is called. The MRF24WB0M will connect ( see page 168) to the SSID in adhoc mode. Note that all the network parameters must be correct before this command is called. see page 166) spaces in the SSID name.
channel channel list all power reenable disable Enables all power saving features (PS_POLL) of the MRF24WB0M. Disables any power savings features. The MRF24WB0M will always be in an active power state. 125 A comma separated list of all the channels to scan. Sets the MRF24WB0M to scan all channels in the given regulatory domain.
WiFi Console
unicast
The MRF24WB0M will be in it's deepest sleep state, only waking up at periodic intervals to check for unicast data. The MRF24WB0M will not wake up on the DTIM period for broadcast or multicast traffic. The MRF24WB0M will wake up to check for all types of traffic (unicast, multicast, and broadcast).
all domain fcc ic etsi spain france japana japanb rts length txrate 0 1 2 scan
United States channels 1-11. Canada channels 1-11. European channels 1-13. Spanish channels 10-11. French channels 10-13. Japanese channel 14. Japanese channels 1-11.
The MRF24WB0M will do automatic rate adaptation between 1 and 2 Mbps. Sets the MRF24WB0M to fixed data rate of 1Mbps. Sets the MRF24WB0M to fixed data rate of 2Mbps.
Instructs the MRF24WB0M to perform an active site scan. Scan results will be displayed to the output terminal. hibernate Removes power to the MRF24WB0M. wakeup Restores power to the MRF24WB0M and reconnects. Note: scan is only supported by the WiFi EZConfig demo.
ifconfig commands take the following structure: ifconfig [ [ [ [ [ <IP address> ] <MAC address> ] netmask <IP address> ] gateway <IP address> ] auto-dhcp <start|drop> ]
WiFi Console
IP address Use a static IP address. IP address must be in dot-decimal notation. Note that this command will return an invalid parameter if the DHCP client is enabled. First disable the DHCP attempts (ifconfig auto-dhcp drop) before running this command. MAC address Redefine the device MAC address. MAC address must be specified in hexadecimal colon notation. This command can only be issued when the MRF24WB0M is in idle mode. Doing so at other times can have unexpected results. netmask IP address Use the specified IP address for the netmask. The netmask value is specified in dot-decimal notation.
gateway IP address auto-dhcp start Starts the DHCP client. Only valid if the DHCP module has been compiled in. DHCP client is started by default. drop Stops the DHCP client. A static IP address will need to be assigned to the device. Only valid if the DHCP module has been compiled in. Configure the gateway address. The gateway value is specified in dot-decimal notation.
iwpriv commands take the following structure: iwpriv [ enc <none|wep|wpa-psk|wpa-phrase> ] [ key <[1]|[2]|[3]|[4]> <value> ] [ psk <value> ] [ phrase <value> ] Note iwpriv by itself will display network security settings. enc none wep wpa-psk The MRF24WB0M will not use any encryption to connect ( network. see page 168) to the specified see
The MRF24WB0M will use either WEP-40 (short) or WEP-104 (long) encryption to connect ( page 168) to the specified network. The MRF24WB0M will use the specified 32-byte PSK to connect ( WPA/WPA2 network.
127
WiFi Console
wpa-phrase
The MRF24WB0M will take the given 1-32 ASCII character passphrase, along with the SSID, and compute the required 32-byte PSK for the network. Note that doing so takes approximately 30 seconds to complete the calculation.
key [1] [2] [3] [4] Instructs the MRF24WB0M to use this key for connecting to the WEP encrypted network. Note that only key 1 is considered safe to use among different AP vendors. Keys 2-4 can have implementation specific entries that may not be compatible from AP to AP. value If value is specified, this will instruct the MRF24WB0M to use the specified key number and also program the device with this key value. For WEP-40 networks, this implies the key is either 5 ASCII characters of 10 hex characters in length. For WEP-104 networks, this implies the key is either 13 ASCII characters or 26 hex characters in length. The console only accepts hex WEP keys. Therefore, the user must do the ASCII to hex conversion for their ASCII keys. psk value 32-byte hex value for the PSK. This value can be calculated from the following website hosted on the Wireshark website. phrase value An 8-63 ASCII character phrase (delimited with quotes if using spaces). This phrase will be used along with the SSID to generate the 32-byte PSK value for the network.
-s -c <IP addr>
Runs the iperf server. No IP address needs to be specified. Runs the iperf client. The IP address is the IP address of the server.
128
WiFi Console
Server side only. Sends UDP datagrams. Specified the time interval, in seconds, that the display will be updated. Specifies the amount of data to try and send. This option is only valid with UDP datagrams. Amount of time, in seconds, to run the test.
Running the Demo After powering on the development board and associating with your wireless network, you'll need to start the server side iperf application first. if you start iperf as a server on the development board in the console, then this implies that you are trying to measure the MRF24WB0M receiver performance. If you start the iperf server on a PC, then you will be measuring MRF24WB0M transmit performance. Below are two images that show receiver and transmitter performance, respectively.
129
WiFi EZConfig
3. Upon connecting, the user can then use a standard web browser to go to the IP address of the demo (http://169.254.1.1). 4. The user will then be presented with some web pages from the web server. The index.htm web page has some additional information on EasyConfig, and also shows the continually updating status of the LEDs, buttons, and potentiometer on the development board. The configure.htm page will allow the user to scan for networks, and connect ( see page 168) to a network of their choosing. 5. The device will then reset itself, using the parameters for the new network. In order to continue using the demo, the client device will now need to reconnect to the same network that the development board is on. Note that the demo will always attempt to connect ( see page 168) to the last known network. If the user wants to reset the demo to startup in adhoc mode again, then button S3 on the Explorer 16 development board needs to be held down for 4 seconds.
130
WiFi EZConfig
Adhoc Networks Upon starting the demo, the network will either connect ( see page 168) to another adhoc network, or will start it's own if one is not found. Adhoc networks are peer-to-peer networks, with no centralized coordinator for the network. All the devices in the network share the responsibilities of keeping the network going. One downfall of adhoc networks is that typically security is not employed on them. The MRF24WB0M module can secure the network with WEP (40-bit/104-bit) security, as can most laptops and adhoc devices. Almost no devices in the market can secure an adhoc network with WPA level security due to the tremendous overhead in doing so. The demo starts an adhoc network with no security. This means that all the network information that is being configured on the device is going over-the-air in the open. For most applications, unless somebody is specifically attempting to eavesdrop on this network, there should be little to no impact on security. However, for applications that do require some baseline level of security, then WEP can be employed on the network. SSL can also be used to encrypt the traffic between the web server and client browser. Additionally, some other form of data-level security can be employed to obfuscate the ASCII network information being sent to the device.
Network Parameters Below is some information on the parameters that are being sent via HTTP POST from the client browser to the device. All this information is being parsed and handled in the function HTTPPostWifiConfig() in CustomHTTPApp.c.
Either adhoc or infrastructure Name of network (1-32 ASCII characters) None WEP-40 (5 ASCII characters or 10 hex numbers) WEP-104 (13 ASCII characters or 26 hex numbers) WPA/WPA2 passphrase (8-63 ASCII characters)
Configured vs Un-configured State When the demo is running in an unconfigured state (i.e, serving the default EasyConfig SSID in adhoc mode), then the heartbeat LED (LED0) will blink twice per second to indicate that it hasn't been configured yet. Once the network has been configured, then the heartbeat LED will change to blink once per second, in a similar fashion to the other TCP/IP demo applications.
EasyConfig Demo Additional Features There are four defines that enable EasyConfig as well as extend it with natural features. STACK_USE_EZ_CONFIG EZ_CONFIG_SCAN EZ_CONFIG_STORE The top level define to enable EasyConfig features. Adds additional ability to instruct the MRF24WB0M module to scan for available networks nearby. This can be done when you are already connected to a network. Store the configuration information for the new network to non-volatile memory. In the event that WPA/WPA2 level security is used, the 32-byte PSK will be saved to NVM. Before switching networks, forces the configuration state machine to pause. This gives the client device additional time to request resources from the development platform before it attempts to connect ( see page 168) to a new network.
EZ_CONFIG_STALL
131
Google PowerMeter
EZ_CONFIG_SCAN The MRF24WB0M has the ability to scan for nearby networks. This is similar to a laptop that can show available wireless networks that can be connected to. The scan results are stored on the MRF24WB0M module, and can be retrieved one at a time from the device. This helps to reduce the impact of storing all the scan results on the host itself. The scan can be performed when idle, or when connected to either an adhoc or infrastructure network.
EZ_CONFIG_STORE The new network parameters can also be stored to non-volatile memory. For the Explorer 16 development board, this information is stored to the 32kB EEPROM on the board. One extremely useful feature of storing the information surfaces when connecting to a network with WPA/WPA2 security. The computation of the 32-byte PSK is computationally heavy, and can take the MRF24WB0M up to 30 seconds to calculate the key. In a normal application, it would be unacceptable to have to wait 30 seconds every time the device started up before connection to the network was established. EZ_CONFIG_STORE helps to alleviate doing the calculation each time by storing the 32-byte PSK to NVM. In doing so, there is only one 30-second hit the very first time the key is calculated only. Successive connections to the network will be significantly faster.
EZ_CONFIG_STALL The configuration state machine that controls the network connections within EasyConfig can employ a wait state between switching networks. From an end user experience, this becomes vital. If the switch between different networks was instantaneous, a client browser would never get an indication that the HTTP session was closed after the POST information was sent. The end user would see this as a browser that was continually waiting, which would eventually timeout. To make the switch more natural and complete, EZ_CONFIG_STALL adds additional time to allow the client to get the remaining web page information. For the demo, this includes a HTTP redirect to a page that highlights the new network information.
Current Incompatibilities The javascript being used in EasyConfig is not compatible with Internet Explorer 7. EasyConfig does work with many other flavors of browser on different architectures, not limited to Internet Explorer 8, Mozilla Firefox, Apple Safari and Google Chrome. The incompatibility is something that is being investigated, and should be fixed in a future stack release.
Energy Monitoring
Application Libraries distribution. To obtain Microchip's Google PowerMeter reference implementation, please download the archived Microchip Application Libraries installation from June, 2011 from www.microchip.com/mal.
133
Required Files
The TCP/IP stack is modular in design and written in the 'C' programming language. It follows the TCP/IP (Internet) protocol suite. The stack currently supports the TCP and UDP transport layer modules, the IPv4 (and part of the ICMP) Internet Layer modules, the ARP link layer modules, and a variety of application layer modules. Most of the Media Access Control link layer functionality is provided by the hardware MAC/PHY chips ( see page 58) used with the stack.
ARP.c and ARP.h- These files are used by the stack to discover the MAC address associated with a given IP address. Delay.c and Delay.h These files are used to provide delays for some stack functions. Note that it would be best to not use these delays in your own code, as they do create blocking conditions. Physical layer files These files are used to enable a specified physical layer. More information on which files to include can be found in the Hardware Configuration ( see page 139) section. Helpers.c and Helpers.h These files contain helper functions used for miscellaneous stack tasks. IP.c and IP.h These files provide internet layer functionality for the stack. StackTsk.c and StackTsk.h These files contain the code to initialize the stack and perform the callbacks that keep the stack going. Tick.c and Tick.h These files implement a tick timer that is used to implement some timing functionality within the stack. HardwareProfile.h This configuration file is used to set up hardware options.
134
Main File
TCPIPConfig.h This configuration file is used to set up firmware options. MAC.h This header file provides macros and structures relating to the hardware MAC layer. TCPIP.h This is the primary include file for the stack. Your main file should include TCPIP.h. You may choose to include additional files to support additional protocols and features. The list of protocols and their required files can be found in the Protocol Macros and Files ( see page 147) topic in the Protocol Configuration ( see page 146) topic.
8.2.3.1 Initialization
You should start by initializing your hardware. This includes PPS pins, oscillators, LEDs, LCDs, any SPI or PMP modules you're using to control your hardware MAC/PHY chip, etc. Next, call the hardware initialization functions for the library. TickInit ( see page 517)() should be called first; it will initialize the tick timer that manages your stack timing. Then call any additional initialization functions that require hardware initialization. For example, the MPFSInit ( see page 281)() function will need to initialize an SPI port to communicate to a memory storage ( see page 139) device to store web pages, so it should be called now. Once your hardware is initialized, you can begin configuring your stack. Most of the stack-related application variables are stored in the AppConfig ( see page 135) structure. At this point, you should initialize the AppConfig structure with your default values, or provide another means of initializing the AppConfig structure. Finally, you can initialize the stack by calling the StackInit() function. This function will automatically call the initialization functions for other firmware protocols if they have been enabled in TCPIPConfig.h (i.e. TCPInit ( see page 467)() for the TCP protocol, HTTPInit ( see page 247)() for HTTP2,...). After StackInit() has been called, you can call other application-specific firmware initialization functions.
Cooperative Multitasking
loop, there are two functions that you must call regularly: StackTask and StackApplications. The StackTask function will perform any timed operations that the stack requires, and will handle transmission and reception of data packets. This function will also route any packets that have been received to the appropriate application protocol-level function to handle it. The StackApplications function will call loaded application modules. For example, if an application is using an HTTP2 see page 248) function to process any server, StackApplications will automatically call the HTTPServer ( HTTP2 tasks that are queued. Most sub-tasks within StackTask and StackApplications are implemented as state-machine controlled cooperative multitasking functions. Since these sub-tasks consists of multiple steps (which may occur at varying times) this call-back system ensures that no single task will monopolize control of the processor. Within this main loop, you may also want to poll for any I/O changes in your application and call any application specific tasks that you've implemented. To avoid causing buffer overflows in your hardware or protocol timing violations you should try to implement your own application tasks in callback functions with timing-based triggers. A method to do this is described in the next topic. You must make one call to StackTask for each call of StackApplications but you aren't required to call these functions with any specific frequency. Calling StackTask too infrequently could limit your throughput, though, as each call of StackTask can retrieve one packet (at most) from the packet buffer. Similarly, application tasks that are time-dependant (like an ICMP ping response) may produce undesirable results if StackApplications is not called frequently enough. The amount of time that the main loop takes to complete one iteration depends on several factors. If data is ready to be transmitted, or if a packet of received data was received, the StackTask function will take more time than it would otherwise. Each additional protocol included in your application will cause the main loop to take additional time as well, with the amount of time for each varying from the length of the shortest state machine state in the task to the longest. Once your application is complete, you can set up a test case to determine the min/average/approximate maximum time that your loop will take to run. You can set your code up to use an internal timer to measure the duration of each iteration of the main loop, or you can set the code up to trigger an output pin each time the main loop completes, and use an oscilloscope to capture the network execution time. You can then provide application inputs or additional network traffic with a PC program (or other PICs) to simulate real-world operating conditions.
Cooperative Multitasking
// Pseudo-initialization function InitializeCode(); // Setup application state gAppState = STATE_DISPLAY_MENU; // Main Loop while (1) { StackTask(); StackApplications(); ApplicationTask(); } } void ApplicationTask (void) { switch (gAppState) { case STATE_DISPLAY_MENU: LCDDisplay (stringMainMenu); gAppState = STATE_MAIN_MENU; break; case STATE_MAIN_MENU: if (ButtonPressDetected (BUTTON_1) ) // Check an input gAppState = STATE_MONITOR_MACHINERY; break; case STATE_MONITOR_MACHINERY: LCDDisplay (stringTransferringData); // Generate or send data if (DataBufferIsFull()) { TransferData(); } else { SampleData(); } if (ButtonPressDetected (BACK_BUTTON) ) gAppState = STATE_DISPLAY_MENU; break; } } Some of the states in your application may be time based. Suppose, for example, that our sample application needs to send data for 5 seconds every time an input is detected. Stack problems could occur if the application used a delay loop to wait for 5 seconds until it was time to stop, so this functionality should be implemented using the stack's built-in tick timer. When the request to send data is received, the code will get the current tick time using the TickGet ( see page 516) function, add enough ticks to make up 5 seconds, save it in a static variable called tickCounter, and then switch to a transmit state. Every time the ApplicationTask function gets called, it will enter this state in the state machine, call TickGet ( see page 516) again, and then compare it to the value stored in that static variable. If the current time is later than the initial time plus the delay, the code will restore the display and re-enter the main menu state. void ApplicationTask (void) { static DWORD tickCounter; switch (gAppState) { case STATE_DISPLAY_MENU: LCDDisplay (stringMainMenu); gAppState = STATE_MAIN_MENU; break; case STATE_MAIN_MENU: if (ButtonPressDetected (BUTTON_1) ) // Check an input gAppState = STATE_MONITOR_MACHINERY; break; case STATE_MONITOR_MACHINERY: LCDDisplay (stringTransferringData); // Save the current time, and add 5 seconds to it tickCounter = TickGet() + (5 * TICK_SECOND); 137
RTOS
gAppState = STATE_CONTINUE_MONITORING; break; case STATE_CONTINUE_MONITORING: if ((long)(TickGet() - tickCounter) > 0) gAppState = STATE_DISPLAY_MENU; else { // Generate or send data if (DataBufferIsFull()) { TransferData(); } else { SampleData(); } } break; } } There are three tick timing macros declared to help with delays: TICK_SECOND ( see page 515) defines the number of ticks in a second, TICK_MINUTE ( see page 515) defines the number of ticks in a minute, and TICK_HOUR ( see page 515) defines the number of ticks in an hour. By using the tick timer to implement delays, you can ensure that your code won't block critical functions for too long.
8.2.5 RTOS
As an alternative to implementing your stack application in a cooperative multitasking format, you can integrate the stack into a Real-Time Operating System. For more information, see Application Note 1264 on the Microchip web site.
138
External Storage
There are also two other clock macros. GetInstructionClock() and GetPeripheralClock() provide frequency values for the instruction clock and peripheral clock in your microcontroller. These values will usually be set as a fraction of the system clock (i.e. GetInstructionClock() would be defines as (GetSystemClock() / 2) for PIC24F processors).
ENC28J60 Config
some changes to support additional EEPROM devices. Serial Flash Storage for MPFS images and custom structures is also available on serial flash devices (tested with SST 25VF016B and Spansion 25FL040A). To indicate that the stack should use serial flash to store web pages, define MPFS_USE_SPI_FLASH in TCPIPConfig.h. The communicaiton macros will be prepended with the string SPIFLASH_ in this case. To enable communication functionality, define SPIFLASH_CS_TRIS and include the files SPIFlash.c and SPIFlash.h in your application. These files may require some changes to support additional flash devices. There are several macros included within SPIFlash.h that must also be defined, including macros to define the sector and page sizes, and macros to describe whether the SST or Spansion flash device is being used. SRAM A serial RAM can be used to store FIFO blocks and TCP Control Blocks for sockets ( see page 149) (tested with AMT Semiconductors N256S0830HDA). The macros will be prepended with the string SPIRAM_ in this case. To use this functionality, define EEPROM_CS_TRIS and include the files SPIRAM.c and SPIRAM.h in your application. These files may require some changes to support additional RAM devices.
Macro xxxxxx_CS_IO
Purpose
Sample Value
Defines the LAT (or PORT, where applicable) register bit that corresponds to LATDbits.LATD12 the chip select pin. Defining this macro will indicate that the stack should use the specified type of external storage. Defines the TRIS bit that corresponds to the chip select pin on the device. TRISDbits.TRISD12
Defines the TRIS bit that corresponds to the clock pin of the SPI module TRISGbits.TRISG6 connected to the device. Defines the TRIS bit that corresponds to the data-in pin of the SPI module TRISGbits.TRISG7 connected to the device. Defines the TRIS bit that corresponds to the data-out pin of the SPI module TRISGbits.TRISG8 connected to the device. Points to the interrupt flag for the SPI module connected to the device. Points to the SPI buffer register for the SPI module connected to the device. Points to the SPI control register for the SPI module connected to the device. IFS2bits.SPI2IF SPI2BUF SPI2CON1
xxxxxx_SPICON1bits Provides bitwise access to the SPI control register for the SPI module SPI2CON1bits connected to the device. The ____bits registers are typically defined in the processors header files. xxxxxx_SPICON2 Points to the second SPI control register for the SPI module connected to the SPI2CON2 device. If your device doesnt have an SPICON2 register (e.g. PIC32) just omit this definition. Points to the SPI status register for the SPI module connected to the device. SPI2STAT
xxxxxx_SPISTAT
xxxxxx_SPISTATbits Provides bitwise access to the SPI status register for the SPI module SPI2STATbits connected to the device. xxxxxx_SPIBRG Points to the SPI Baud Rate Generator register for the SPI module connected SPI2BRG to the device. If your device doesnt have a BRG-based SPI module, just omit this definition.
140
ENCX24J600 Config
#define ENC_CS_TRIS xxxxxxxxxxxxxxx Several macros need to be mapped to registers or register bits when using the ENC28J60. They include: Macro ENC_CS_IO Purpose Sample Value
Defines the LAT (or PORT, where applicable) register bit that corresponds to the LATDbits.LATD14 chip select pin. Defining this macro will also indicate that the stack should use the ENC28J60. Defines the TRIS bit that corresponds to the chip select pin. TRISDbits.TRISD14
ENC_CS_TRIS ENC_RST_IO
Defines the LAT (or PORT, where applicable) register bit that corresponds to the LATDbits.LATD15 reset pin. If you leave the reset pin unconnected in your design, comment this macro out. Defines the TRIS bit that corresponds to the reset pin. Points to the interrupt flag for the SPI module connected to the chip. Points to the SPI buffer register for the SPI module connected to the chip. Points to the SPI status register for the SPI module connected to the chip. TRISDbits.TRISD15 IFS0bits.SPI1IF SPI1BUF SPI1STAT
ENC_SPISTATbits Provides bitwise access to the SPI status register for the SPI module connected SPI1STATbits to the chip. The ____bits registers are typically defined in the processors header files. ENC_SPICON1 Points to the SPI control register for the SPI module connected to the chip. SPI1CON1
ENC_SPICON1bits Provides bitwise access to the SPI control register for the SPI module connected SPI1CON1bits to the chip (see ENC_SPISTATbits entry). ENC_SPICON2 Points to the second SPI control register for the SPI module connected to the SPI1CON2 chip. If your device doesnt have an SPICON2 register (e.g. PIC32) just omit this definition. Points to the SPI Baud Rate Generator register for the SPI module connected to SPI1BRG the chip. If your device doesnt have a BRG-based SPI module, just omit this definition.
ENC_SPIBRG
More information on the functionality of each mode is available in the ENC624J600 family datasheet. Note, however, that the 141
ENCX24J600 Config
44-pin ENC424J600 only supports communication using the SPI mode and PSP Modes 5 and 6. Also, because of board conflicts, PSP Modes 2, 4, 6, and 10 shouldnt be used with the Explorer 16 (and PSP Mode 3 may cause bus contention with the 25LC256 EEPROM). Several macros need to be mapped to registers or register bits when using the ENCX24J600 as well. In addition, some features can be enabled/disabled for this device by defining certain macros. Macros include: Macro ENC100_INTERFACE_MODE Purpose Sample Value
Indicates which communication mode the stack should use 0 to interface to the chip. This macro will also indicate that the stack should use the ENCX24J600. Un-commenting this macro will allow the stack to indirectly N/A address the RAM of the ENCX24J600 (to save some address wires). For SPI mode or PSP Modes 9 and 10, this option will be ignored. This macro will actually remap the addresses passed into the ((((a)&0x100)<<6) parallel interface to fit the configuration of the pins (if you are ((a&0x00FF)) using indirect addressing). If you design an Auto-crossover (Auto-MDIX) circuit into your LATBbits.LATB3 board, this macro will define the pin to use for it. See the Fast 100Mbps Ethernet PICtail/PICtail Plus board schematic for an example circuit. Defines the TRIS bit to use for the Auto-crossover circuit. TRISBbits.TRISB3 |
ENC100_PSP_USE_INDIRECT_RAM_ADDRESSING
ENC100_TRANSLATE_TO_PIN_ADDR(a) ENC100_MDIX_IO
Defines an I/O pin to use for the chips interrupt signal pin. PORTAbits.RA13 This feature is currently unused by the stack. Defines a TRIS bit to use for the chips interrupt signal pin. TRISAbits.TRISA13
Defines a port bit for use with the chip select pin. Optional in LATAbits.LATA5 PSP modes. Defines a TRIS bit to use for the chip select pin. TRISAbits.TRISA5
Defines the port bit to use with a power disconnect circuit. If LATCbits.LATC1 your application doesnt have this feature implemented, comment out this bit. Defines the TRIS bit to use with a power disconnect circuit. TRISCbits.TRISC1
ENC100_POR_TRIS ENC100_SO_WR_B0SEL_EN_IO
Defines a pin used for communication. The functionality of LATDbits.LATD4 this pin depends on which communication mode in selected. It can be equivalent to the ENCX24J600 serial out pin, the parallel mode WR strobe, the B0SEL pin, or the EN pin. use with the TRISDbits.TRISD4
Defines a pin used for communication. The functionality of LATDbits.LATD5 this pin depends on which communication mode in selected. It can be equivalent to the ENCX24J600 serial in pin, the parallel mode RD strobe, or the R/~W pin. Defines the TRIS bit to use with the ENC100_SI_RD_RW_IO TRISDbits.TRISD5 pin. Defines a pin used for communication. The functionality of LATDbits.LATDB15 this pin depends on which communication mode in selected. It can be equivalent to the ENCX24J600 serial clock pin or the parallel mode address latch strobe. Defines the TRIS bit to use with the ENC100_SCK_AL_IO TRISDbits.TRISD15 pin. Points to the bit to enable the interrupt for the I/O based IEC1bits.INT2IE ENCX24J600-triggered interrupt. This feature is not currently implemented.
ENC100_SI_RD_RW_TRIS ENC100_SCK_AL_IO
ENC100_SCK_AL_TRIS ENC100_ISR_ENABLE
142
PIC32MX7XX Config
ENC100_ISR_FLAG
Points to the interrupt flag bit for the I/O based IFS1bits.INT2IF ENCX24J600-triggered interrupt. This feature is not currently implemented. Points to the interrupt polarity bit for the I/O based INTCON2bits.INT2EP ENCX24J600-triggered interrupt. This feature is not currently implemented. Points to the interrupt priority bit for the I/O based IPC7bits.INT2IP ENCX24J600-triggered interrupt. This feature is not currently implemented. Points to the SPI module enable bit if SPI mode is used. SPI1STATbits.SPIEN
ENC100_ISR_POLARITY
ENC100_ISR_PRIORITY
Points to the interrupt flag for the SPI module if SPI mode is IFS0bits.SPI1IF used. Points to the SPI buffer register for the SPI module if SPI SPI1BUF mode is used. Points to the SPI status register for the SPI module if SPI SPI1STAT mode is used. Provides bitwise access to the SPI status register for the SPI SPI1STATbits if SPI mode is used. The ____bits registers are typically defined in the processors header files. Points to the SPI control register for the SPI module if SPI SPI1CON1 mode is used. Provides bitwise access to the SPI control register for the SPI1CON1bits SPI module if SPI mode is used (see ENC_SPISTATbits entry). Points to the second SPI control register for the SPI module SPI1CON2 if SPI mode is used. If your device doesnt have an SPICON2 register (e.g. PIC32) just omit this definition. Points to the SPI Baud Rate Generator register for the SPI SPI1BRG module if SPI mode is used. If your device doesnt have a BRG-based SPI module, just omit this definition.
ENC100_SPICON1 ENC100_SPICON1bits
ENC100_SPICON2
ENC100_SPIBRG
143
9.2 Address
MAC Address
Macro PHY_RMII
Purpose
Sample Value
Define this macro if the external PHY runs in RMII mode. Comment it out if youre using an MII PHY.
PHY_CONFIG_ALTERNATE Define this symbol if the PIC32MX7XX uses the alternate configuration pins to connect ( see page 168) to the PHY. Comment it out for the default configuration pins. PHY_ADDRESS Update with the MIIM address of the external PHY you are using (the address on 0x1 which the PHY responds to MIIM transactions. See the PHY datasheet).
Update the following definitions in TCPIPConfig.h: Macro ETH_CFG_LINK Purpose Sample Value
Set to 0 to use the default connection characteristics (depends on the selected PHY). 0 Set to 1 to configure the Ethernet link to the following specific parameters. Auto-negotiation will always be enabled if supported by the PHY. Set to 1 to use auto negotiation. Strongly recommended. Use/advertise 10 Mbps capability. Use/advertise 100 Mbps capability. Use/advertise half duplex capability. Use/advertise full duplex capability. 1 1 1 1 1
ETH_CFG_AUTO_MDIX Use/advertise auto MDIX capability (effective only when ETH_CFG_AUTO is enabled). 1 ETH_CFG_SWAP_MDIX Use swapped MDIX if defined. Otherwise, use normal MDIX. 1
9.2 Address
A TCP/IP application will need to have both a Media Access Control (MAC) address and an Internet Protocol (IP) address. There are multiple methods for obtaining or setting these addresses.
144
9.2 Address
IP Address
MY_DEFAULT_MAC_BYTE5 MY_DEFAULT_MAC_BYTE6
(0x00) (0x00)
Each of these macros represents a byte of the MAC address (note that 00:04:A3:xx:xx:xx is the block of MAC addresses reserved for Microchip products). Once you obtain your block of addresses, you will need to specify a unique address for every device you produce. The "TCP/IP Demo App" demonstration project describes a method for using Microchip's MPLAB PM3 programmer to serially program a range of MAC addresses into multiple parts without recompiling your project. The ENCX24J600, MRF24WB0M, and PIC32MX7XX/6XX feature a pre-programmed MAC address (from Microchip's address block). If you are using either of these part families in your project, you can define your MAC address as "00:04:A3:00:00:00" and the stack will automatically use the part's pre-programmed address for your application. Microchip also provides a family of EEPROMs that include a unique, pre-programmed EUI-48 (MAC) or EUI-64 address. When using one of these devices, you can write your AppConfig ( see page 135) initialization code so it will obtain the device's MAC address from one of these EEPROMs instead of the default MAC address macros.
9.2.2 IP Address
The IP address is used to address nodes on an Internet Protocol network. You will need to configure your application with an IP address, or enable a method to obtain one. You may also want to define a few other parameters that describe how your device will try to fit into its network, by default. The macros that you will need to define include: Macro MY_DEFAULT_IP_ADDR_BYTE1 MY_DEFAULT_IP_ADDR_BYTE2 MY_DEFAULT_IP_ADDR_BYTE3 MY_DEFAULT_IP_ADDR_BYTE4 MY_DEFAULT_MASK_BYTE1 MY_DEFAULT_MASK_BYTE2 MY_DEFAULT_MASK_BYTE3 MY_DEFAULT_MASK_BYTE4 MY_DEFAULT_GATE_BYTE1 MY_DEFAULT_GATE_BYTE1 MY_DEFAULT_GATE_BYTE1 MY_DEFAULT_GATE_BYTE1 Property Default IP address byte 1 Default IP address byte 2 Default IP address byte 3 Default IP address byte 4 Default subnet mask byte 1 Default subnet mask byte 2 Default subnet mask byte 3 Default subnet mask byte 4 Default gateway byte 1 Default gateway byte 2 Default gateway byte 3 Default gateway byte 4 Sample Value 192ul 168ul 1ul 100ul 255ul 255ul 255ul 0ul 192ul 168ul 1ul 1ul
The subnet address is a bit mask that defines the scope of the network. If your IP address is 192.168.5.100, and you specify a subnet mask of 255.255.255.0, the stack will assume that addresses in the range 192.168.5.x are on the same subnet that you are, and that packets sent to any of those addresses won't have to be routed anywhere else. The default gateway is the IP address of the node on the network that your application will send packets to if it doesn't know how to route them to the address it wants to send them to. If your application is on the 192.268.5.x subnet, if it wants to send a packet to 198.175.253.160 and it doesn't know exactly how to get there, it will send it to the default gateway. Note that if you write your own code instead of starting with a demo application, you will need to populate your AppConfig ( see page 135) structure with these values. Also note that these are only default values. Other protocols (or your application itself) may modify any of the APP_CONFIG fields that represent these parameters.
145
There are three methods that you can use to set or obtain an IP address: static, DHCP, or AutoIP. Static IP Addressing Using a static address will allow you to specify a set IP address. This can either be done at compile time, by setting the default IP address to the value you'd like to use and using the demo code (which populated your AppConfig structure automatically), or during run-time, by programming your application to set the IP address in your AppConfig structure based on some input. If you'd like to include the code for DCHP and AutoIP address acquisition if your project but still use static addressing, you can call the DHCP and AutoIP functions that disable those modules to prevent them from overwriting your IP address. Use of static addresses will usually only work if the server is configured to support that address. DHCP The DHCP client module will allow your application to dynamically obtain an IP address from a DHCP server on the same network. Doing this will reset the IP address, subnet mask, gateway address, and some other configuration parameters in your AppConfig structure. To use DHCP, include the files DHCP.c, DHCPs.c, and DHCP.h in your project, and add or uncomment the definition "#define STACK_USE_DHCP_CLIENT" to TCPIPConfig.h. The TCP/IP stack also includes a simple DHCP server that can supply an IP address to one DHCP client. To enable this functionality, add the macro "#define STACK_USE_DHCP_SERVER" to TCPIPConfig.h. AutoIP The AutoIP module will allow your application to choose an IP address and claim it for itself. These addresses are link-local, meaning they cannot be routed, and will only work on your local link. This functionality is based on the specification for allocating dynamic link-local addresses, but is modified to take the form used by Microsoft's APIPA link-local address allocation scheme. To enable this feature, include the files AutoIP.c and AutoIP.h and add the macro "#define STACK_USE_AUTO_IP" to TCPIPConfig.h. IP Address ( see page 144) Module Interaction
It is possible to configure a default static address and enable DHCP and AutoIP at the same time. If you don't disable one or the other, the AutoIP module will immediately choose an address in the specified address range and begin attempting to claim it. DHCP will also begin sending messages to attempt to lease a DHCP IP address from a DHCP server. In most cases the DHCP module will complete all of its transactions before AutoIP finishes claiming its address. In this case, the DHCP address will be copied to the AppConfig structure and the AutoIP module will stop trying to claim its address. Since a routable DHCP address is always preferred to a link-local AutoIP address, the stack will also immediately start using a DHCP address if it becomes available, even if an AutoIP address was already in use (i.e. if you enable DHCP after AutoIP has already claimed an address). This may cause existing open sockets to lose communication; they should be re-opened with the new address. In this situation, you can also use a static address if you disable DHCP and AutoIP and set the static address in the AppConfig structure. If AutoIP is used in conjunction with the DHCP Server module, the AutoIP module will generate an address in the 169.254.x.x subnet and then serve another address in the same subnet to the DHCP client connected to the board.
ICMP ( STACK_USE_ICMP_SERVER see page 260) ICMP ( STACK_USE_ICMP_CLIENT see page 260) HTTP2 ( STACK_USE_HTTP2_SERVER see page 227)
ICMP.c, ICMP.h
HTTP2.h, Provides HTTP server functionality with HTTP2.c, dynamic variables, POST, Cookies ( see TCP.c, TCP.h, page 88), Authentication ( see page 86), CustomHTTPApp.c HTTPPrint.h and other features and (see HTTP2 ( see page 227) section for information on these files) Provides support for SSL server sockets. SSL.c, SSL.h, ARCFOUR.c, ARCFOUR.h, BigInt.c, BigInt.h, Random.c, Random.h, RSA.c, RSA.h SSL.c, SSL.h, ARCFOUR.c, ARCFOUR.h, BigInt.c, BigInt.h, Random.c, Random.h, RSA.c, RSA.h
FTP
STACK_USE_FTP_SERVER
Provides ability to remotely upload MPFS2 FTP.c, FTP.h, TCP.c, images to HTTP2 servers via FTP TCP.h Provides the ability to send email SMTP.c, SMTP.h, TCP.c, TCP.h, Helpers.c, Helpers.h machine SNMP.c, SNMP.h, UDP.c, UDP.h
SMTP ( STACK_USE_SMTP_CLIENT see page 294) SNMP ( STACK_USE_SNMP_SERVER see page 315) TFTP ( STACK_USE_TFTP_CLIENT see page 489) Telnet ( STACK_USE_TELNET_SERVER see page 485) Announce STACK_USE_ANNOUNCE ( see page 152)
Provides device hostname and IP address Announce.c, discovery on a local Ethernet subnet Announce.h
147
Additional Features
DNS ( STACK_USE_DNS see page 181) NBNS ( STACK_USE_NBNS see page 287) SNTP ( STACK_USE_SNTP_CLIENT see page 370)
Provides the ability to resolve hostnames to DNS.c, DNS.h, UDP.c, IP addresses UDP.h Provides the ability to resolve hostnames to NBNS.c, NBNS.h, IP addresses on the same subnet. UDP.c, UDP.h Provides the ability to get the date/time from SNTP.c, SNTP.h, the internet UDP.c, UDP.h
Dynamic STACK_USE_DYNAMICDNS_CLIENT Provides the ability to resolve hostnames to DynDNS.c, DynDNS.h, DNS ( IP addresses that change frequently. TCP.c, TCP.h see page 190) MPFS2 STACK_USE_MPFS2 ( see page 268) TCP ( STACK_USE_TCP see page 439) Provides MPFS2 services for custom MPFS2.c, MPFS2.h applications. This functionality will be enabled/required automatically by stack-based protocols that require MPFS2. Provides TCP transport layer services for TCP.c, TCP.h custom protocols. This functionality is automatically enabled/required by stack-based protocols that require TCP sockets. Provides UDP transport layer services for UDP.c, UDP.h custom protocols. This functionality is automatically enabled/required by stack-based protocols that require UDP sockets.
Application demo using UART.c, UART.h UART for IP address display and stack configuration. UART to TCP application example Bridge UART2TCPBridge.c, UART2TCPBridge.h
STACK_USE_UART2TCP_BRIDGE STACK_USE_IP_GLEANING
Allows assignment of an IP address via reception of an ICMP packet with a valid IP during configuration mode Allows the PIC to be reset Reboot.c, Reboot.h remotely (useful for bootloaders).
STACK_USE_REBOOT_SERVER
UDP STACK_USE_UDP_PERFORMANCE_TEST UDP performance test. UDPPerformanceTest.c, Performance Test Monitor a local area network ( see page 290) for UDP packets with a UDPPerformanceTest.h packet sniffer. This test will transmit 1024 packets. Use the timestamps of the first and last packets to calculate throughput.
148
Sockets
TCP performance test. TCPPerformanceTest.c, Connect a demo board to a TCPPerformanceTest.h PC via UART, execute the code, and monitor the throughput on the PC terminal. Provides a Berkeley Sockets BerkeleyAPI.c, ( see page 149) API BerkeleyAPI.h abstraction layer.
STACK_USE_BERKELEY_API
9.3.3 Sockets
Most of your application protocols will require you to allocate memory for each connection (socket) that you have open. Like the other firmware configuration options, this is controlled by the definition of macros in TCPIPConfig.h. For TCP sockets, you will have to specify four initialization parameters for each socket, including the purpose of that socket, the type of memory the socket should be stored in, the size of the transmit FIFO, and the size of the receive FIFO. The stack will then initialize the sockets with this information, and create a TCP Control Block (TCB) for each to control its operations. This topic will outline the socket configuration functionality in the sample version of TCPIPConfig.h that is included with the TCP/IP Demo App project.
The first four macros in the socket section are used to describe the total amount of memory used to contain sockets. When data is sent from a TCP socket, it will first be copied into the socket's transmit FIFO, and then to the MAC/PHY transmit buffer. Similarly, received data will be read from the MAC/PHY chip into the receive FIFO. These FIFOs, as well as the TCB, can be stored in 3 places. TCP_ETH_RAM_SIZE is used to define the RAM available for sockets on the actual TCP/IP MAC/PHY chip. This will not be the same as the total RAM on the chip; some memory must be reserved for packets being transmitted and received. By default ~1518 bytes (the maximum single-packet transmission size) will be reserved for TX packets on Microchip parts. The amount reserved for the receive packet buffer will equal the amount remaining after allocating the memory for the TX buffer and the memory for the sockets. You may receive a compile-time warning if the RX buffer is unreasonably small. TCP_PIC_RAM_SIZE is used to define the RAM available for sockets on the PIC microcontroller that's driving your application. TCP_SPI_RAM_SIZE defines the RAM available for sockets on an external SPI RAM (see External Storage ( 139)). You can specify the base address in this RAM chip to use with the TCP_SPI_RAM_BASE_ADDRESS macro. see page
Sockets
#define TCP_PURPOSE_FTP_COMMAND 3 #define TCP_PURPOSE_FTP_DATA 4 #define TCP_PURPOSE_TCP_PERFORMANCE_TX 5 #define TCP_PURPOSE_TCP_PERFORMANCE_RX 6 #define TCP_PURPOSE_UART_2_TCP_BRIDGE 7 #define TCP_PURPOSE_HTTP_SERVER 8 #define TCP_PURPOSE_DEFAULT 9 #define TCP_PURPOSE_BERKELEY_SERVER 10 #define TCP_PURPOSE_BERKELEY_CLIENT 11 #define END_OF_TCP_SOCKET_TYPES The TCP_PURPOSE_GENERIC_TCP_CLIENT and TCP_PURPOSE_GENERIC_TCP_SERVER socket types are used by the generic TCP client and server examples (see GenericTCPClient.c and GenericTCPServer.c). These files are used as an example of how to create a new, custom TCP client or server application. If you are trying to open a Telnet ( see page 485) connection, the stack will try to use a TCP_PURPOSE_TELNET socket.
The TCP_PURPOSE_FTP_COMMAND and TCP_PURPOSE_FTP_DATA socket types are used to receive FTP commands and data. The two TCP_PERFORMANCE_x socket types are used solely to conduct TCP performance testing. The TCP_PURPOSE_UART_2_TCP_BRIDGE socket type is used for the UART-to-TCP bridge example. The TCP_PURPOSE_HTTP_SERVER socket type is used for sockets on HTTP servers that listen ( page view requests. see page 172) for web
The TCP_PURPOSE_DEFAULT socket type can be used for miscellaneous applications, or for applications that only need sockets temporairly. Dynamic DNS connections and SMTP connections use default sockets, and the legacy wrapper implementation for the TCPListen ( see page 455) and TCPConnect ( see page 445) functions try to open them. The TCP_PURPOSE_BERKELEY_SERVER and TCP_PURPOSE_BERKELEY_CLIENT socket types indicate that a socket is available for the use of the Berkeley API ( see page 164) layer (also see BSD Sockets ( see page 151)).
150
9.3 Protocol Configuration Socket purpose/type RAM storage location TX FIFO buffer size RX FIFO buffer size
Sockets
Several example socket declarations are listed. The socket purpose for each corresponds to one of the socket types ( see page 149). The RAM storage for each socket example sets the location to TCP_ETH_RAM (the MAC/PHY chip RAM). Other options are TCP_PIC_RAM (the PIC's own RAM) and TCP_SPI_RAM (an external SPI RAM device). Finally, the TX and RX FIFOs are declared. Each RX buffer must contain at least one byte, to handle the SYN and FIN messages required by TCP. Each socket you declare will require up to 48 bytes of PIC RAM, and 40 + (TX FIFO size) + (RX FIFO size) bytes of RAM on the storage medium that you select.
151
10.1 Announce
10 Stack API
Modules Name Announce ( ARP ( see page 152) see page 154) see page 181) see page 190) Description Provides a UDP MAC address announcement feature. Provides Address ( see page 144) Resolution Protocol support.
Berkeley (BSD) Sockets ( DNS Client ( Hashes ( Helpers ( ICMP ( MPFS2 ( NBNS ( Dynamic DNS Client (
see page 164) Provides a BSD socket wrapper to the Microchip TCP/IP Stack. Provides Domain Name Service resolution. Updates an external IP address to a Dynamic DNS service. Calculates MD5 and SHA-1 hash sums. Provides several helper function for stack operation. Provides an advanced embedded web server. Provides Ping functionality. Provides a light-weight file system. Describes the NetBIOS Name Service protocol. Tests TCP and UDP performance of an application. Sends e-mail messages across the internet. Provides a service to remotely reboot the PIC. Provides an Simple Network Management Protocol agent. Obtains absolute time stamps from a pool of network time servers. Implements SSL encryption for TCP connections. Implements the TCP transport layer protocol. Describes the operation of the Telnet module. Describes the TFTP module. Provides accurate time-keeping capabilities. Implements the UDP transport layer protocol.
see page 199) see page 209) see page 227) see page 260) see page 268) see page 287) see page 290) see page 294)
HTTP2 Server (
Performance Tests ( SMTP Client ( Reboot ( SNMP ( SSL ( TCP ( Telnet ( TFTP ( UDP (
SNTP Client (
see page 375) see page 439) see page 485) see page 489) see page 513) see page 520)
Tick Module (
Description The Microchip TCP/IP Stack is implemented as a suite of modules. Each module exists on its own layer in the TCP/IP layer model, and has its own set of APIs. These APIs are described in this section
10.1 Announce
This module will facilitate device discovery on DHCP enabled networks by broadcasting a UDP message on port 30303 whenever the local IP address changes. You can change the port used by the announce module by changing the following macro definition in Announce.c. #define ANNOUNCE_PORT 30303 see page 62) PC program.
152
10.1 Announce
The following functions and variables are public, but are intended only to be accessed by the stack itself. Applications should generally not call these functions or modify these variables.
153
Recurring task used to listen ( see page 172) for Discovery messages on the specified ANNOUNCE_PORT. These messages can be sent using the Microchip Device Discoverer tool. If one is received, this function will transmit a reply. Remarks A UDP socket must be available before this function is called. It is freed at the end of the function. MAX_UDP_SOCKETS may need to be increased if other modules use UDP sockets. Preconditions Stack is initialized()
10.2 ARP
Types Name ARP_PACKET ( 163) Description The Address ( see page 144) Resolution Protocol, or ARP, is a foundation layer of TCP/IP. It translates IP addresses to physical MAC addresses, or locates a gateway through which a machine may be located. TCP and UDP applications will not need to access ARP directly. The TCPOpen ( page 524) functions will handle both ARP and DNS operations transparently. see page 455) and UDPOpen ( see see page Description ARP packet structure
Responses to incoming ARP requests are processed automatically. Resolution of ARP requests follows a simple state machine, as indicated in the following diagram.
ARPIsResolved ( 156)
154
10.2 ARP ARPDeRegisterCallbacks ( see page 156) ARPRegisterCallbacks ( see page 157) ARPSendPkt ( 157) Macros Name ARP_REQ ( ARP_RESP ( see page 158) see see page
De-Registering callbacks with ARP module that are registered previously. Registering callback with ARP module to get notified about certian events. Transmits an ARP request/Reply initated by Application or external module.
Description Operation code indicating an ARP Request MAX num allowed registrations of Modules/Apps see page 158) Operation code indicating an ARP Response
Structures Name arp_app_callbacks ( page 158) Description The following functions and variables are available to the stack application. see Description This is record arp_app_callbacks.
155
10.2 ARP
10.2 ARP Preconditions ARP packet is ready in the MAC buffer. Parameters Parameters SrcIPAddr DestIPAddr op_req
Description The Source IP-address The Destination IP-Address ( see page 144) see page 158)/ARP_RESP ( see page Operation Request (ARP_REQ ( 158))
158
Description The following functions and variables are public, but are intended only to be accessed by the stack itself. Applications should generally not call these functions or modify these variables.
159
Retrieves an ARP packet from the MAC buffer and determines if it is a response to our request (in which case the ARP is resolved) or if it is a request requiring our response (in which case we transmit one.) Preconditions ARP packet is ready in the MAC buffer. Return Values Return Values TRUE FALSE Description All processing of this ARP packet is complete. Do not call again until a new ARP packet is waiting in the RX buffer. This function must be called again. More time is needed to send an ARP response.
Description The following functions and variables are designated as internal to the ARP module.
160
10.2 ARP
161
10.2 ARP
162
10.2 ARP C NODE_INFO Cache; Description Cache for one ARP response
Types
10.2.4 Types
Module ARP ( see page 154)
Structures Name ARP_PACKET ( 163) see page Description ARP packet structure
10.3 Berkeley (BSD) Sockets BYTE MACAddrLen; BYTE ProtocolLen; WORD Operation; MAC_ADDR SenderMACAddr; IP_ADDR SenderIPAddr; MAC_ADDR TargetMACAddr; IP_ADDR TargetIPAddr; Description ARP packet structure
Length of addresses used in the upper-layer protocol (4). The operation the sender is performing (ARP_REQ ( ARP_RESP ( see page 158)). The sender's hardware (MAC) address. The sender's IP address. The target node's hardware (MAC) address. The target node's IP address. see page 158) or
164
Description see page 167) see page 170) see Internet Address ( see page 144) Family - UDP, TCP, etc. IP address for server binding. Invalide TCP port IP Address ( see page 144) for server binding
INADDR_ANY (
Indicates IP pseudo-protocol.
see page 171) Indicates TCP for the internet address family. see page 171) Indicates UDP for the internet address family. see page 175) Connectionless datagram socket. Use UDP for the internet address family. see page Connection based byte streams. Use TCP for the internet address family.
SOCKET_CNXN_IN_PROGRESS Socket connection state. ( see page 177) SOCKET_DISCONNECTED ( see page 178) SOCKET_ERROR ( 178) Module Berkeley (BSD) Sockets ( see page 164) see page Socket disconnected Socket error
165
10.3 Berkeley (BSD) Sockets Structures Name BSDSocket ( in_addr ( sockaddr ( see page 170) see page 175)
Description see page 167) Berkeley Socket structure in_addr structure generic address structure for all address families
Description see page generic address structure for all address families
The following functions and variables are available to the stack application.
Parameters Parameters s addr addrlen Description Socket descriptor returned from a previous call to socket. must be bound to a local name and in listening mode. Optional pointer to a buffer that receives the address of the connecting entity. Optional pointer to an integer that contains the length of the address addr
166
10.3 Berkeley (BSD) Sockets WORD remotePort; DWORD remoteIP; int backlog; BOOL isServer; TCP_SOCKET SocketID; }; Members Members int SocketType; BSD_SCK_STATE bsdState; WORD localPort; WORD remotePort; DWORD remoteIP; int backlog; BOOL isServer; TCP_SOCKET SocketID; Description Berkeley Socket structure
Description Socket type Socket state local port remote port remote IP maximum number or client connection server/client check Socket ID
168
10.3 Berkeley (BSD) Sockets C int connect( SOCKET s, struct sockaddr* name, int namelen ); Returns
If the connect() function succeeds, it returns 0. Otherwise, the value SOCKET_ERROR ( see page 178) is returned to indicate an error condition. For stream based socket, if the connection is not established yet, connect returns SOCKET_CNXN_IN_PROGRESS ( see page 177). Description The connect function assigns the address of the peer communications endpoint. For stream sockets, connection is established between the endpoints. For datagram sockets, an address filter is established between the endpoints until changed with another connect() function. Remarks None. Preconditions socket function should be called. Parameters Parameters s name namelen Description Socket descriptor returned from a previous call to socket. pointer to the sockaddr ( and port number. length of the sockaddr ( see page 175) structure containing the peer address see page 175) structure.
169
Description Pointer to a buffer that receives the local host name. size of the name array.
IP address in Byte
IP address in Word
IP address
171
10.3 Berkeley (BSD) Sockets C #define IPPROTO_UDP 17 Description Indicates UDP for the internet address family.
available. A return value of SOCKET_ERROR ( see page 178) (-1) indicates an error condition. A return value of SOCKET_DISCONNECTED ( see page 178) indicates the connection no longer exists. Description The recv() function is used to receive incoming data that has been queued for a socket. This function can be used with both datagram and stream socket. If the available data is too large to fit in the supplied application buffer buf, excess bytes are discarded in case of SOCK_DGRAM ( see page 175) type sockets. For SOCK_STREAM ( see page 175) types, the data is buffered internally so the application can retreive all data by multiple calls of recvfrom ( see page 173). Remarks None. Preconditions connect ( see page 168) function should be called for TCP and UDP sockets. Server side, accept ( function should be called. Parameters Parameters s buf len flags Description Socket descriptor returned from a previous call to socket. application data receive buffer. buffer length in bytes. no significance in this implementation see page 166)
Microchip TCP/IP Stack Help application data receive buffer. buffer length in bytes. message flags. Currently this is not supported. pointer to the sockaddr ( destination address.
On success, sendto returns number of bytes sent. In case of error returns SOCKET_ERROR ( Description
The sendto function is used to send outgoing data on a socket. The destination address is given by to and tolen. Both Datagram and stream sockets are supported. Remarks None. Preconditions socket function should be called. Parameters Parameters s buf len flags to Description Socket descriptor returned from a previous call to socket. application data buffer containing data to transmit. length of data in bytes. message flags. Currently this field is not supported. Optional pointer to the the sockaddr ( see page 175) structure containing the destination address. If NULL, the currently bound remote port and IP address are used as the destination. length of the sockaddr ( see page 175) structure.
tolen
10.3 Berkeley (BSD) Sockets C struct sockaddr { unsigned short sa_family; char sa_data[14]; }; Members Members unsigned short sa_family; char sa_data[14]; Description
176
#define SOCKET_CNXN_IN_PROGRESS (-2) //Socket connection state. Description Socket connection state.
178
This function initializes the Berkeley socket array. This function should be called before any BSD socket call. Remarks None. Preconditions None.
HandlePossibleTCPDisconnection Internal function that checks for asynchronous TCP connection state ( see page 180) changes and resynchs the BSD socket descriptor state to match. Module Berkeley (BSD) Sockets ( Variables Name BSDSocketArray ( page 180) gAutoPortNumber ( page 180) Description The following functions and variables are designated as internal to the module. see see Description Array of BSDSocket ( see page 167) elements; used to track all socket state and connection information. Contains the next local port number to associate with a socket. see page 164)
179
10.3 Berkeley (BSD) Sockets Members Members SKT_CLOSED SKT_CREATED SKT_BOUND SKT_BSD_LISTEN SKT_LISTEN SKT_IN_PROGRESS SKT_EST SKT_DISCONNECTED Description Berkeley Socket (BSD) states
Description Socket closed state indicating a free descriptor Socket created state for TCP and UDP sockets Socket bound state for TCP and UDP sockets Listening state for TCP BSD listener handle "socket TCP server listen ( see page 172) state TCP client connection in progress state TCP client or server established state TCP client or server no longer connected to the remote host (but was historically)
Description TCP type socket descriptor returned from a previous call to socket. This socket must be in the SKT_LISTEN, SKT_IN_PROGRESS, SKT_EST, or SKT_DISCONNECTED states.
Description see page Constant for record type in DNSResolve ( (standard address) record. see page 183). Indicates an A
181
10.4 DNS Client DNS_TYPE_MX ( 185) Module DNS Client ( Description see page 181)
Microchip TCP/IP Stack Help see page Constant for record type in DNSResolve ( (mail exchanger) record.
The following functions and variables are available to the stack application.
182
Description The address to the host name was successfully resolved. The DNS failed or the address does not exist.
Only one DNS resoultion may be executed at a time. The Hostname must not be modified in memory until the resolution is complete. Remarks This function requires access to one UDP socket. If none are available, MAX_UDP_SOCKETS may need to be increased. This function is aliased to DNSResolve ( Preconditions DNSBeginUsage ( Parameters Parameters Hostname RecordType ( see page 188) Description A pointer to the null terminated string specifiying the host for which to resolve an IP. DNS_TYPE_A ( see page 184) or DNS_TYPE_MX ( see page 185) depending on what type of record resolution is desired. see page 182) returned TRUE on a previous call. see page 183) on non-PIC18 platforms.
FALSE
184
DNSPutROMString ( page 186) DNSDiscardName ( page 189) Macros Name DNS_PORT ( 187)
DNS_TIMEOUT ( 187) Module DNS Client ( Structures Name DNS_HEADER ( 189) Variables Name DNSHostName ( 187) see page 181)
see page Elapsed time after which a DNS resolution is considered to have timed out
Description see page see Host name in RAM to look up Host name in ROM to look up Stores various flags for the UDP module Record type being queried
see page
185
Microchip TCP/IP Stack Help Node information about the resolved node State machine for a DNS query
The following functions and variables are designated as internal to the DNS module.
186
187
10.5 Dynamic DNS Client DNS_GET_RESULT, DNS_FAIL, DNS_DONE } smDNS; Members Members DNS_START = 0 DNS_ARP_START_RESOLVE DNS_ARP_RESOLVE DNS_OPEN_SOCKET DNS_QUERY DNS_GET_RESULT DNS_FAIL DNS_DONE Description State machine for a DNS query
Description Initial state to reset client state variables Send ARP resolution of DNS server or gateway MAC address Wait for response to ARP request Open UDP socket Send DNS query to DNS server Wait for response from DNS server ARP or DNS server not responding DNS query is finished
189
see page Status message for DynDNS ( see page 190) client. GOOD and NOCHG are ok, but ABUSE through 911 are fatal. UNCHANGED through INVALID are locally defined.
see page Returns the last known external IP address of the device. see Returns the status of the most recent update. Selects a pre-configured Dynamic DNS service
DDNSGetLastStatus ( page 194) DDNSSetService ( page 194) Module Dynamic DNS Client ( Structures Name DDNS_POINTERS ( page 191) Variables Name DDNSClient (
see
190
These functions and variables are meant to be called by your stack application.
The username and password pair do not match a real user. An option available only to credited users (such as offline URL) was specified, but the user is not a credited user. If multiple hosts were specified, only a single !donator will be returned. The hostname specified is not a fully-qualified domain name (not in the form hostname.dyndns.org or domain.com). The hostname specified does not exist in this user account (or is not in the service specified in the system parameter). The hostname specified does not belong to this user account. Too many hosts specified in an update. Unspecified DNS error encountered by the DDNS service. There is a problem or scheduled maintenance with the DDNS service. Error communicating with Update service. The IP Check indicated that no update was necessary. Error communicating with CheckIP service. DDNS Client data is not valid. DDNS client has not yet been executed with this configuration.
DDNS_STATUS_NOT_FQDN DDNS_STATUS_NOHOST DDNS_STATUS_NOT_YOURS DDNS_STATUS_NUMHOST DDNS_STATUS_DNSERR DDNS_STATUS_911 DDNS_STATUS_UPDATE_ERROR DDNS_STATUS_UNCHANGED DDNS_STATUS_CHECKIP_ERROR DDNS_STATUS_INVALID DDNS_STATUS_UNKNOWN Description
Status message for DynDNS ( see page 190) client. GOOD and NOCHG are ok, but ABUSE through 911 are fatal. UNCHANGED through INVALID are locally defined.
193
Description one of the DDNS_SERVICES ( selected service see page 192) elements to indicate the
195
This function performs the background tasks of the Dynamic DNS Client. Once the DDNSPointers structure is configured, this task attempt to update the Dynamic DNS hostname on a periodic schedule. The task first accesses the CheckIP server to determine the device's current external IP address. If the IP address has changed, it issues an update command to the dynamic DNS service to propagate the change. This sequence executes whenever dwUpdateAt ( see page 197) elapses, which by default is every 10 minutes, or when an update is forced. Remarks This function acts as a task (similar to one in an RTOS). It performs its task in a co-operative manner, and the main application must call this function periodically to ensure that its tasks get executed in a timely fashion. Preconditions DDNSInit ( Section Function Prototypes see page 195)() has been called.
ddnsServiceHosts ( page 197) ddnsServicePorts ( page 197) dwUpdateAt ( 197) lastKnownIP ( 197) lastStatus (
The following functions and variables are designated as internal to the Dynamic DNS module.
196
197
10.5 Dynamic DNS Client C IP_ADDR lastKnownIP; Description Last known IP address of this device
198
10.6 Hashes
10.6 Hashes
The Hashes module calculates MD5 and/or SHA-1 hash sums of data. Hash sums are one-way digest functions, meaning that the original message cannot be derived from the hash of the message. Collisions, while exceedingly rare, do exist. However, they are extremely difficult to create. Hash functions are generally used for message integrity and authentication purposes. They are used extensively by encryption protocols such as SSL to verify that a message has not been tampered with during transit. The following flow diagram demonstrates how to use this module.
To use the hash functions, first declare a HASH_SUM ( see page 203) structure and pass a pointer to it to either MD5Initialize ( see page 202) or SHA1Initialize ( see page 202). Then, call HashAddData ( see page 200) or HashAddROMData ( see page 200) as many times as are necessary to provide all the data to the hash. Call MD5Calculate ( see page 201) or SHA1Calculate ( see page 202) at any time to obtain the hash sum up to the current point. After calculation, continue adding data and repeating this process as many times as necessary.
199
10.6 Hashes MD5Calculate ( 201) MD5Initialize ( 202) see page see page see page see page
Microchip TCP/IP Stack Help Calculates an MD5 hash Initializes a new MD5 hash. Calculates a SHA-1 hash Initializes a new SHA-1 hash.
SHA1Calculate ( 202) SHA1Initialize ( 202) Module Hashes ( Structures Name HASH_SUM ( 203) Description see page 199)
The following functions and variables are available to the stack application.
200
10.6 Hashes C void HashAddROMData( HASH_SUM* theSum, ROM BYTE* data, WORD len ); Returns None Description Adds data to the hash sum. Remarks
This function calls the appropriate hashing function based on the hash typed defined in theSum. This function is aliased to HashAddData ( Preconditions The hash sum has already been initialized Parameters Parameters theSum data len Description hash context state the data to be added to the hash sum length of data see page 200) on non-PIC18 platforms.
201
10.6 Hashes
202
10.6 Hashes C void SHA1Initialize( HASH_SUM* theSum ); Returns None Description Initializes a new SHA-1 hash. Preconditions None Parameters Parameters theSum Section Function Prototypes
Description pointer to the allocated HASH_SUM ( SHA-1 see page 203) object to initialize as
203
10.6 Hashes
204
10.6 Hashes
205
206
The following functions and variables are designated as internal to the Hashes (
207
10.6 Hashes C typedef enum { HASH_MD5 = 0u, HASH_SHA1 } HASH_TYPE; Members Members HASH_MD5 = 0u HASH_SHA1 Description Type of hash being calculated
208
10.7 Helpers
10.7 Helpers
Functions Name LFSRRand ( Description see page 225) Returns a pseudo-random 16-bit unsigned integer in the range from 0 to 65535 (0x0000 to 0xFFFF). see page Seeds the LFSR random number generator invoked by the LFSRRand ( page 225)() function. The prior seed is returned. see
Description see Default Random Number Generator seed. 0x41FE9F9E corresponds to calling LFSRSeedRand ( see page 226)(1)
This module contains several helper functions used throughout the TCP/IP Stack. Some of these duplicate functionality already implemented in the compiler's default libraries. In those cases, the compiler's version is used and the stack's version 209
CalcIPBufferChecksum ( see page 213) CalcIPChecksum ( page 213) ExtractURLFields ( page 214) see see
GenerateRandomDWORD ( see page 217) hexatob ( see page 218) see leftRotateDWORD ( page 218) Replace (
ROMStringToIPAddress ( see page 220) stricmppgm2ram ( page 221) StringToIPAddress ( page 221) strupr ( strnchr ( swapl ( swaps ( uitoa ( ultoa ( see see
see page 222) see page 222) see page 223) see page 223) see page 224) see page 224) see page
Description see Rotations are more efficient in C30 and C32 Non-ROM variant for C30 and C32
210
The following functions and variables are available to the stack application.
211
Encoding cannot be performed in-place. If cSourceData overlaps with cDestData, the behavior is undefined. Encoded data is always at least 1/3 larger than the source data. It may be 1 or 2 bytes larger than that. Preconditions None Parameters Parameters cSourceData wSourceLen cDestData Description Pointer to a string of binary data Length of the binary source data Maximum length that can be written to cDestData Pointer to write the Base-64 encoded data
212
Converts the lower nibble of a binary value to a hexadecimal ASCII byte. For example, btohexa_high ( 212)(0xAE) will return 'E'. Preconditions None Parameters Parameters b Description the byte to convert
see page
10.7 Helpers
complement sum of all words in the data (with zero-padding if an odd number of bytes are summed). This checksum is defined in RFC 793. Internal This function could be improved to do 32-bit sums on PIC32 platforms. Preconditions buffer is WORD aligned (even memory address) on 16- and 32-bit PICs. Parameters Parameters buffer count Description pointer to the data to be checksummed number of bytes to be checksummed
214
Description Pointer to null terminated URL to decode and extract from. This parameter is required and needs to have the minimum RFC 1738 components in it (protocol and hostname). Optional pointer to a PROTOCOLS enum to retrieve the decoded protocol type. If this parameter is unneeded, specify a NULL pointer. The protocol is a required part of the URL, so it must always be present. The protocol also determines what scheme all other parameters are decoded using, so the function will fail if an unrecognized protocol is provided. The PROTOCOLS enum members show all of the currently supported protocols for this function. For the example URL provided in the function description, PROTOCOL_HTTP would be returned for this field.
protocol
vUsername
Optional pointer to a buffer to write the decoded username portion of the URL. If the URL does not contain a username or a NULL pointer is supplied, then this field is ignored. For the example URL provided in the function description, "admin" would be returned for this field.
wUsernameLen
On call: Optional pointer to a WORD specifying the maximum length of the vUsername buffer, including the null terminator character. Upon return: If wUsernameLen and vUsername are non-NULL, the *wUsernameLen WORD is updated with the actual number of characters written to the vUsername buffer, including the null terminator character. If vUsername is NULL but wUsernameLen is non-NULL, then no characters are copied, but *wUsernameLen will return the number of characters required to fit the full username string. If wUsernameLen is NULL, then the username field in the URL, if present, is ignored and the vUsername pointer is not used. If zero characters were written, this indicates that the URL did not contain a username field. If one character was written, this indicates that a username field was present, but was a zero character string (ex: ""). For the example URL provided in the function description, 6 (0x0006) would be returned for this field.
vPassword
Optional pointer to a buffer to write the decoded password portion of the URL. If the URL does not contain a password or a NULL pointer is supplied, then this field is ignored. For the example URL provided in the function description, "passwd" would be returned for this field.
215
On call: Optional pointer to a WORD specifying the maximum length of the vPassword buffer, including the null terminator character. Upon return: If wPasswordLen and vPassword are non-NULL, the *wPasswordLen WORD is updated with the actual number of characters written to the vPassword buffer, including the null terminator character. If vPassword is NULL but wPasswordLen is non-NULL, then no characters are copied, but *wPasswordLen will return the number of characters required to fit the full password string. If wPasswordLen is NULL, then the password field in the URL, if present, is ignored and the vPassword pointer is not used. If zero characters were written, this indicates that the URL did not contain a password field. If one character was written, this indicates that a password field was present, but was a zero character string (ex: ""). For the example URL provided in the function description, 7 (0x0007) would be returned for this field.
vHostname
Optional pointer to a buffer to write the decoded hostname portion of the URL. All Internet URLs must contain a hostname or IP address, however, if a NULL pointer is supplied, then this field is ignored. For the example URL provided in the function description, "www.microchip.com" would be returned for this field. If the URL was "http://192.168.0.1", then this field would be returned as "192.168.0.1". The IP address would not be decoded to a DWORD (use the StringToIPAddress ( see page 221)() helper function to do this).
wHostnameLen
On call: Optional pointer to a WORD specifying the maximum length of the vHostname buffer, including the null terminator character. Upon return: If wHostnameLen and vHostname are non-NULL, the *wHostnameLen WORD is updated with the actual number of characters written to the vHostname buffer, including the null terminator character. If vHostname is NULL but wHostnameLen is non-NULL, then no characters are copied, but *wHostnameLen will return the number of characters required to fit the full hostname string. If wHostnameLen is NULL, then the hostname field in the URL, is ignored and the vHostname pointer is not used. For the example URL provided in the function description, 18 (0x0012) would be returned for this field. If the URL was "http://192.168.0.1", then this field would be returned as 12 (0x000C).
wPort
Optional pointer to a WORD specifying the TCP or UDP port that the server is listening on. If the port field is absent from the URL, then this parameter will specify the default port for the protocol. For example, "http://www.microchip.com" would result in 80 being return as the specified port. If the wPort pointer is NULL, then the port field in the URL is ignored, if present.
vFilePath
Optional pointer to a buffer to write the decoded file path portion of the URL. If a NULL pointer is supplied, then this field is ignored. If a file path is not present in the URL, then "/" will be returned in this field. For the example URL provided in the function description, "/myfile.gif" would be returned for this field.
216
On call: Optional pointer to a WORD specifying the maximum length of the vFilePath buffer, including the null terminator character. Upon return: If wFilePathLen and vFilePath are non-NULL, the *wFilePathLen WORD is updated with the actual number of characters written to the vFilePath buffer, including the null terminator character. If vFilePath is NULL but wFilePathLen is non-NULL, then no characters are copied, but *wFilePathLen will return the number of characters required to fit the full file path string. If wFilePathLen is NULL, then the file path field in the URL, if present, is ignored and the vFilePath pointer is not used. This function always returns "/" if no file path is present, so *wFilePathLen will also be at least 2 characters ('/' and null terminator) if the pointer is non-NULL. For the example URL provided in the function description, 12 (0x000C) would be returned for this field.
217
This function generates a random 32-bit integer. It collects randomness by comparing the A/D converter's internal R/C oscillator clock with our main system clock. By passing collected entropy to the LFSRSeedRand ( see page 226)()/LFSRRand ( see page 225)() functions, the output is normalized (deskewed) in the hopes of meeting statistical randomness tests. Remarks This function times out after 1 second of attempting to generate the random DWORD. In such a case, the output may not be truly random. Typically, this function executes in around 500,000 instruction cycles. The intent of this function is to produce statistically random and cryptographically secure random number. Whether or not this is true on all (or any) devices/voltages/temperatures is not tested. Preconditions None
This function rotates the bits in a 32-bit DWORD left by a specific number of bits. Remarks This function is only implemented on 8-bit platforms for now. The 8-bit compilers generate excessive code for this function, while C30 and C32 already generate compact code. Those compilers are served by a macro defined in Helpers.h. Preconditions None Parameters Parameters val bits Description the DWORD to be rotated the number of bits by which to shift
219
10.7 Helpers
of the string and proceed to the beginning (right to left searching). In this case if the expression was "aaa", find was "aa", and replacement was "bbb", then the final output expression will be "abbb". Preconditions This function is commented out by default to save code space because it is not used by any current stack features. However, if you want to use it, go ahead and uncomment it. It has been tested, so it (should) work correctly. Parameters Parameters vExpression vFind vReplacement wMaxLen Description Null terminated string to search and make replacements within. Null terminated string to search for. Null terminated string to replace all instances of vFind with. Maximum length of the output vExpression string if string expansion is going to occur (replacement length is longer than find length). If the replacements will cause this maximum string length to be exceeded, then no replacements will be made and a negative result will be returned, indicating failure. If the replacement length is shorter or equal to the search length, then this parameter is ignored. Boolean indicating if the search should be performed in a case insensitive manner. Specify TRUE for case insensitive searches (slower) or FALSE for case sensitive searching (faster).
bSearchCaseInsensitive
220
10.7 Helpers
221
10.7 Helpers Preconditions None Parameters Parameters str IPAddress Return Values Return Values TRUE FALSE
Description Pointer to a dotted-quad IP address string Pointer to IP_ADDR in which to store the result
Description an IP address was successfully decoded no IP address could be found, or the format was incorrect
10.7 Helpers
occurance location is returned. If the search character is not present in the string, or if the maximum character count is reached first, then a NULL pointer is returned. Preconditions None Parameters Parameters searchString count c Description Pointer to a null terminated string to search. If count is less than the string size, then the string need not be null terminated. Maximum number of characters to search before aborting. Character to search for
223
224
Functions
Description The number to be converted Pointer in which to store the converted string
10.7.2 Functions
Functions Name LFSRRand ( Description see page 225) Returns a pseudo-random 16-bit unsigned integer in the range from 0 to 65535 (0x0000 to 0xFFFF). see page Seeds the LFSR random number generator invoked by the LFSRRand ( page 225)() function. The prior seed is returned. see
225
Variables
The internal LFSR seed is updated so that the next call to LFSRRand() will return a different random number. Returns Random 16-bit unsigned integer. Description Returns a pseudo-random 16-bit unsigned integer in the range from 0 to 65535 (0x0000 to 0xFFFF). The random number is generated using a Linear Feedback Shift Register (LFSR) type pseudo-random number generator algorithm. The LFSR can be seeded by calling the LFSRSeedRand ( see page 226)() function to generate the same sequence of random numbers as a prior string of calls. The internal LFSR will repeat after 2^32-1 iterations. Remarks None Preconditions None
226
10.7.3 Variables
Module Helpers ( Variables Name dwLFSRRandSeed ( page 227) see Description Default Random Number Generator seed. 0x41FE9F9E corresponds to calling LFSRSeedRand ( see page 226)(1) see page 209)
Web Pages This includes all the HTML and associated images, CSS stylesheets, and JavaScript files necessary to display the website. A sample application including all these components is located in the WebPages2 folder. MPFS2 Utility This program, supplied by Microchip, packages the web pages into a format that can be efficiently stored in either external non-volatile storage, or internal flash program memory. This program also indexes dynamic variables found in the web pages and updates HTTPPrint.h with these indices. If external storage is being used, the MPFS2 Utility outputs a BIN file and can upload that file directly to the board. If the data is being stored in Flash program memory, the MPFS2 Utility will generate a C source file image to be included in the project. 227
HTTP2 Features
When dynamic variables are added or removed from your application, the MPFS2 Utility will update HTTPPrint.h. When this happens, the project must be recompiled in the MPLAB IDE to ensure that all the new variable indices get added into the application. CustomHTTPApp.c This file implements the web application. It describes the output for dynamic variables (via HTTPPrint_varname ( see page 243) callbacks), parses data submitted through forms (in HTTPExecuteGet ( see page 239) and HTTPExecutePost ( see page 240)) and validates authorization credentials (in HTTPAuthenticate). The exact functionality of these callbacks is described within the demo application's web pages, and is also documented within the CustomHTTPApp.c example that is distributed with the stack. HTTPPrint.h This file is generated automatically by the MPFS2 Utility. It indexes all the dynamic variables and provides the "glue" between the variables located in the web pages and their associated HTTPPrint_varname ( see page 243) callback functions defined in CustomHTTPApp.c. This file does not require modification by the programmer.
HTTP2 Features
The following code inserts the value of the push buttons into the web page, all using the same callback function: <div class="examplebox code">btn(3)~ btn(2)~ btn(1)~ btn(0)~</div> This associated callback will print the value of the requested button to the web page: void HTTPPrint_btn(WORD num) { // Determine which button switch(num) { case 0: num = BUTTON0_IO; break; case 1: num = BUTTON1_IO; break; case 2: num = BUTTON2_IO; break; case 3: num = BUTTON3_IO; break; default: num = 0; } // Print the output if(num == 1) TCPPutROMString(sktHTTP, "up"); else TCPPutROMString(sktHTTP, "down"); } Longer Outputs The HTTP protocol operates in a fixed memory buffer for transmission, so not all data can be sent at once. Care must be taken inside of your callback function to avoid overrunning this buffer. The HTTP2 web server verifies that at least 16 bytes are free in this buffer before invoking a callback. For short outputs (less than 16 bytes), callbacks need only to call the appropriate TCPPut ( see page 458) function and return. For longer outputs, callback functions must check how much space is available, write up to that many bytes, then return. The callback will be invoked again when more space is free. To manage the output state, callbacks should make use of curHTTP.callbackPos. This DWORD value is set to zero when a callback is first invoked. If a callback is only writing part of its output, it should set this field to a non-zero value to indicate that it should be called again when more space is available. This value will be available to the callback during the next call, which allows the function to resume output where it left off. A common use is to store the number of bytes written, or remaining to be written, in this field. Once the callback is finished writing its output, it must set curHTTP.callbackPos back to zero in order to indicate completion. As an example, this code outputs the current value of the LCD display, which is 32 bytes on many Microchip development boards: <div class="examplebox code">~lcdtext~</div> The following callback function handles the output, and manages its state for multiple calls: void HTTPPrint_lcdtext(void) { WORD len; // Determine how many bytes we can write len = TCPIsPutReady(sktHTTP); // If just starting, set callbackPos if(curHTTP.callbackPos == 0) curHTTP.callbackPos = 32; // Write a byte at a time while we still can 229
HTTP2 Features
// It may take up to 12 bytes to write a character // (spaces and newlines are longer) while(len > 12 && curHTTP.callbackPos) { // After 16 bytes write a newline if(curHTTP.callbackPos == 16) len -= TCPPutROMString(sktHTTP, (ROM BYTE*)"<br />"); if(LCDText[32-curHTTP.callbackPos] == ' ' || LCDText[32-curHTTP.callbackPos] == '\0') len -= TCPPutROMString(sktHTTP, (ROM BYTE*)" "); else len -= TCPPut(sktHTTP, LCDText[32-curHTTP.callbackPos]); curHTTP.callbackPos--; } } The initial call to TCPIsPutReady ( see page 454) determines how many bytes can be written to the buffer right now. The TCPPut ( see page 458) functions all return the number of bytes written, so we can subtract that value from len to track how much buffer space is left. When buffer space is exhausted, the function exits and waits to be called again. For subsequent calls, the value of curHTTP.callbackPos is exactly as we left it. The function resumes its output at that point. Including Files Often it is useful to include the entire contents of another file in your output. Most web pages have at least some portion that does not change, such as the header, menu of links, and footer. These sections can be abstracted out into separate files which makes them easier to manage and conserves storage space. To include the entire contents of another file, use a dynamic variable that starts with "inc:", such as ~inc:header.inc~. This sequence will cause the file header.inc to be read from the file system and inserted at this location. The following example indicates how to include a standard menu bar section into every page: <div id="menu">~inc:menu.inc~</div> At this time, dynamic variables are not recursive, so any variables located inside files included in this manner are not parsed.
230
HTTP2 Features
GET /leds.htm?led1=1&led3=1 HTTP/1.1 The HTTP2 web server will parse this request and store the following string in curHTTP.data: "led1\01\0led3\01\0\0" It will then call HTTPExecuteGet ( see page 239) to process this input. To process this data, that callback needs to do several things. First, it should call MPFSGetFilename ( see page 274) to verify which form was submitted. (This step may be omitted if only one form is provided by the application.) Next, since a checkbox control was used a default state of unchecked must be assumed. Finally, the callback should search for each argument it expects, compare the value, and set the LED pins accordingly. The following example satisfies all these requirements: HTTP_IO_RESULT HTTPExecuteGet(void) { BYTE *ptr, filename[20]; // Load the file name (filename[] must be large enough to hold // the longest file name expected) MPFSGetFilename(curHTTP.file, filename, 20); // Verify the file name if(!strcmppgm2ram(filename, (ROM char*)"leds.htm")) { // Assume a default state of off LED1_IO = 0; LED2_IO = 0; LED3_IO = 0; // Search for each LED parameter and process ptr = HTTPGetROMArg(curHTTP.data, (ROM BYTE*)"led1"); if(ptr) LED1_IO = (*ptr == '1'); ptr = HTTPGetROMArg(curHTTP.data, (ROM BYTE*)"led2"); if(ptr) LED2_IO = (*ptr == '1'); ptr = HTTPGetROMArg(curHTTP.data, (ROM BYTE*)"led3"); if(ptr) LED3_IO = (*ptr == '1'); } // Indicate completion return HTTP_IO_DONE; } The POST Method The POST method transmits data after all the request headers have been sent. This data is not visible in the browser's address bar, and can only be seen with a packet capture tool. It does however use the same URL encoding method. The HTTP2 server does not perform any pre-parsing of this data. All POST data is left in the TCP buffer, so the custom application will need to access the TCP buffer directly to retrieve and decode it. The functions HTTPReadPostName ( see page 244) and HTTPReadPostValue ( see page 245) have been provided to assist with these requirements. However, these functions can only be used when at least entire variables are expected to fit in the TCP buffer at once. Most POST processing functions will be implemented as state machines in order to use these functions. The variable curHTTP.smPost is available to store the current state. This state machine variable is reset to zero with each new request. Functions should generally implement a state to read a variable name, and another to read an expected value. Additional states may be helpful depending on the application. The following example form accepts an e-mail address, a subject, and a message body. Since this data will likely total over 100 bytes, it should be submitted via POST. <form method="post" action="/email.htm"> To: <input type="text" name="to" maxlength="50" /><br /> Subject: <input type="text" name="subject" maxlength="50" /><br /> Message:<br /> <textarea name="msg" rows="6"></textarea><br /> 231
HTTP2 Features
<input type="submit" value="Send Message" /></div> </form> Suppose a user enters the following data into this form: To: joe@picsaregood.com Subject: Sent by a PIC Message: I sent this message using my development board! The HTTPExecutePost ( see page 240) function will be called with the following data still in the TCP buffer:
to=joe%40picsaregood.com&subject=Sent+by+a+PIC &msg=I+sent+this+message+using+my+development+board%21 To use the e-mail module, the application needs to read in the address and the subject, store those in RAM, then send the message. However, since the message is not guaranteed to fit in RAM all at once, it must be read as space is available and passed to the e-mail module. A state machine, coupled with the HTTPReadPostName ( see page 244) and HTTPReadPostValue ( see page 245) functions can simplify this greatly. The following example callback function will properly parse this input. For this example, it is assumed that this is the only form the board accepts, so file name checking is not performed. The address will be stored at curHTTP.data[0:49], and the subject will be stored at curHTTP.data[50:99]. This is not the most optimal solution, but serves as a simple example. HTTP_IO_RESULT HTTPExecutePost(void) { BYTE *dest, temp[16]; // Define state machine values #define SM_READ_NAME (0u) #define SM_READ_VALUE (1u) #define SM_START_MESSAGE (2u) #define SM_SEND_MESSAGE (3u) switch(curHTTP.smPost) { case SM_READ_NAME: // Read the next variable name. If a complete name is // not found, request more data. This function will // automatically truncate invalid data to prevent // buffer overflows. if(HTTPReadPostName(temp,16) == HTTP_READ_INCOMPLETE) return HTTP_IO_NEED_DATA; // Save "to" values to curHTTP.data[0:49] if(!strcmppgm2ram((char*)temp, (ROM char*)"to")) dest = curHTTP.data; // Save "subject" values to curHTTP.data[50:99] else if(!strcmppgm2ram((char*)temp, (ROM char*)"subject")) dest = curHTTP.data + 50; // When a "msg" is encountered, start sending else if(!strcmppgm2ram((char*)temp, (ROM char*)"msg")) { curHTTP.smPost = SM_START_MESSAGE; break; } // Ignore unexpected values else dest = NULL; // Move to the next state, but do not break yet curHTTP.smPost = SM_READ_VALUE; case SM_READ_VALUE: // Read the next value. If a complete value is // not found, request more data. This function will // automatically truncate invalid data to prevent // buffer overflows. if(HTTPReadPostValue(dest,50) == HTTP_READ_INCOMPLETE) return HTTP_IO_NEED_DATA; 232
HTTP2 Features
// Return to read a new name curHTTP.smPost = SM_READ_NAME; break; case SM_START_MESSAGE: // TODO: Perform necessary tasks to start sending the message. // Move on to sending the message body curHTTP.smPost = SM_SEND_MESSAGE; break; case SM_SEND_MESSAGE: // The message may be longer than the TCP buffer can hold // at once. To avoid errors, read the data piece by // piece and send it to the e-mail module. This requires // using TCP functions directly. // Send all remaining data while(curHTTP.byteCount > 0) { // First check if data is ready if(TCPIsGetReady(sktHTTP) == 0) return HTTP_IO_NEED_DATA; // TODO: Read data with TCPGetArray and send // it to the e-mail module. } // Process is complete return HTTP_IO_DONE; } // Assume return for state machine convenience. // Do not return HTTP_IO_NEED_DATA here by default, because // doing so when more data will not arrive is cause for // the HTTP2 server to return an error to the user. return HTTP_IO_WAITING; } The previous example uses the HTTPReadPostName ( see page 244) and HTTPReadPostValue ( see page 245) functions, and also demonstrates using the need to use TCPIsGetReady ( see page 454), TCPGet ( see page 450), and TCPGetArray ( see page 451) when longer values are expected. For applications that will receive and react to parameters immediately and have no need for a state machine, a simple while loop can be written around HTTPReadPostPair ( see page 245) to accomplish the callback. The HTTPPostLCD ( see page 91) function in the TCPIP Demo App provides a simple example of this. For more examples, refer to CustomHTTPApp.c in the TCPIP Demo App project.
HTTP2 Features
password protection. This function returns a value to instruct the HTTP2 server how to proceed. The most significant bit indicates whether or not access is granted. That is, values 0x80 and higher allow access unconditionally, while values 0x79 and lower will require a user name and password at a later point. The value returned is stored as curHTTP.isAuthorized so that it can be accessed by future callback functions. The following example is the simplest case, in which all files require a password for access: BYTE HTTPNeedsAuth(BYTE* cFile) { return 0x00; } In some cases, only certain files will need to be protected. The second example requires a password for any file located in the /treasure folder: BYTE HTTPNeedsAuth(BYTE* cFile) { // Compare to "/treasure" folder. Don't use strcmp here, because // cFile has additional path info such as "/treasure/gold.htm" if(!memcmppgm2ram((void*)cFile, (ROM void*)"treasure", 8)) return 0x00; return 0x80; } More complex uses could require an administrative user to access the /admin folder, while any authenticated user can access the rest of the site. The third example requires a different set of user name and password combinations for the /admin folder versus the rest of the site: #define HTTP_AUTH_ADMIN #define HTTP_AUTH_OTHER (0x00) (0x01)
BYTE HTTPNeedsAuth(BYTE* cFile) { // Return a specific code for admin users if(!memcmppgm2ram((void*)cFile, (ROM void*)"admin", 5)) return HTTP_AUTH_ADMIN; return HTTP_AUTH_OTHER; } Validating Credentials The HTTPCheckAuth ( see page 238) function determines if the supplied user name and password are valid to access this resource. Again, the most significant bit indicates whether or not access is granted. The value returned is also stored as curHTTP.isAuthorized so that it can be accessed by future callback functions. The following example is the simplest case, in which one user/password pair is accepted for all pages: BYTE HTTPCheckAuth(BYTE* cUser, BYTE* cPass) { if(!strcmppgm2ram((char*)cUser, (ROM char*)"AliBaba") && !strcmppgm2ram((char*)cPass, (ROM char*)"Open Sesame!") ) return 0x80; return 0x00; } In some cases, you may have multiple users with various levels of access. The following example satisfies the needs used in the third example of HTTPNeedsAuth ( see page 242) above: BYTE HTTPCheckAuth(BYTE* cUser, BYTE* cPass) { // Check for admin users first if(curHTTP.isAuthorized == HTTP_AUTH_ADMIN && !strcmppgm2ram((char*)cUser, (ROM char*)"admin") && !strcmppgm2ram((char*)cPass, (ROM char*)"s3cREt") ) return 0x80; if(!strcmppgm2ram((char*)cUser, (ROM char*)"kate") && !strcmppgm2ram((char*)cPass, (ROM char*)"puppies!") ) 234
HTTP2 Features
More complex uses are certainly feasible. Many applications may choose to store the user names and passwords in EEPROM or other non-volatile storage so that they may be updated by the end-user. Some applications may wish to return various values above 0x80 in HTTPCheckAuth ( see page 238) so that later callback functions can determine which user logged in. The flexibility of these functions provides for many more possibilities that are not documented here but can be developed in just a few hours.
The MPFS2 Utility will automatically determine which files can benefit from GZIP compression, and will store the compressed file in the MPFS2 image when possible. This generally includes all JavaScript and CSS files. (Images are typically already compressed, so the MPFS2 Utility will generally decide it is better to store them uncompressed.) This HTTP server will then seamlessly return this compressed file to the browser. Less non-volatile storage space will be required for the MPFS2 image, and faster transfers back to the client will result. No special configuration is required for this feature. To prevent certain extensions from being compressed, use the Advanced Settings dialog in the MPFS2 Utility.
HTTP_READ_STATUS ( see page 238) Functions Name HTTPCheckAuth ( page 238) HTTPExecuteGet ( page 239) HTTPExecutePost ( page 240) HTTPGetArg ( 241) see see see
Description Performs validation on a specific user name and password. Processes GET form field variables and cookies. Processes POST form variables and data. Locates a form field value in a given data array. Locates a form field value in a given data array. Determines if a given file name requires authentication Inserts dynamic content into a web page
HTTPPrint_varname ( page 243) HTTPReadPostName ( page 244) HTTPReadPostValue ( page 245) HTTPURLDecode ( page 246) Macros Name HTTPReadPostPair ( page 245) sktHTTP ( Module HTTP2 Server ( Structures Name HTTP_CONN ( 237) see page 227)
see Reads a name from a URL encoded string in the TCP buffer. see Reads a value from a URL encoded string in the TCP buffer. Parses a string from URL encoding to plain-text.
see
Description see Reads a name and value pair from a URL encoded string in the TCP buffer. Access the current socket
Description see page Stores extended state data for each connection
236
10.8 HTTP2 Server Variables Name curHTTP ( Description see page 237)
The following functions and variables are accessible or implemented by the stack application.
237
10.8 HTTP2 Server HTTP_FILE_TYPE fileType; BYTE data[HTTP_MAX_DATA_LEN]; BYTE smPost; Description
Microchip TCP/IP Stack Help File type to return with Content-Type General purpose data buffer POST state machine variable
10.8 HTTP2 Server C BYTE HTTPCheckAuth( BYTE* cUser, BYTE* cPass ); Description
This function is implemented by the application developer in CustomHTTPApp.c. Its function is to determine if the user name and password supplied by the client are acceptable for this resource. The value of curHTTP.isAuthorized will be set to the previous return value of HTTPRequiresAuthorization. This callback function can check this value to determine if only specific user names or passwords will be accepted for this resource. Return values 0x80 - 0xff indicate that the credentials were accepted, while values from 0x00 to 0x79 indicate that authorization failed. While most applications will only use a single value to grant access, flexibility is provided to store multiple values in order to indicate which user (or user's group) logged in. The return value of this function is saved as curHTTP.isAuthorized, and will be available to future callbacks, including any of the HTTPExecuteGet ( see page 239), HTTPExecutePost ( see page 240), or HTTPPrint_varname ( see page 243) callbacks. Remarks This function is only called when an Authorization header is encountered. This function may NOT write to the TCP buffer. Internal See documentation in the TCP/IP Stack API or HTTP2.h for details. Preconditions None Parameters Parameters cUser cPass Return Values Return Values <= 0x79 >= 0x80 Description the credentials were rejected access is granted for this connection Description the user name supplied by the client the password supplied by the client
once the application is done with the values. Any data placed there will be available to future callbacks for this connection, including HTTPExecutePost ( see page 240) and any HTTPPrint_varname ( see page 243) dynamic substitutions. This function may also issue redirections by setting curHTTP.data to the destination file name or URL, and curHTTP.httpStatus to HTTP_REDIRECT. Finally, this function may set cookies. Set curHTTP.data to a series of name/value string pairs (in the same format in which parameters arrive) and then set curHTTP.hasArgs equal to the number of cookie name/value pairs. The cookies will be transmitted to the browser, and any future requests will have those values available in curHTTP.data. Remarks This function is only called if variables are received via URL parameters or Cookie arguments. This function may NOT write to the TCP buffer. This function may service multiple HTTP requests simultaneously. Exercise caution when using global or static variables inside this routine. Use curHTTP.callbackPos or curHTTP.data for storage associated with individual requests. Internal See documentation in the TCP/IP Stack API or HTTP2.h for details. Preconditions None Return Values Return Values HTTP_IO_DONE HTTP_IO_NEED_DATA HTTP_IO_WAITING Description application is done processing this value may not be returned because more data will not become available the application is waiting for an asynchronous process to complete, and this function should be called again later
and avoids browser warnings about "resubmitting form data". Redirects may be issued to the browser by setting curHTTP.data to the destination file or URL, and curHTTP.httpStatus to HTTP_REDIRECT. Finally, this function may set cookies. Set curHTTP.data to a series of name/value string pairs (in the same format in which parameters arrive) and then set curHTTP.hasArgs equal to the number of cookie name/value pairs. The cookies will be transmitted to the browser, and any future requests will have those values available in curHTTP.data. Remarks This function is only called when the request method is POST, and is only used when HTTP_USE_POST is defined. This method may NOT write to the TCP buffer. This function may service multiple HTTP requests simultaneously. Exercise caution when using global or static variables inside this routine. Use curHTTP.callbackPos or curHTTP.data for storage associated with individual requests. Internal See documentation in the TCP/IP Stack API or HTTP2.h for details. Preconditions None Return Values Return Values HTTP_IO_DONE HTTP_IO_NEED_DATA HTTP_IO_WAITING Description application is done processing more data is needed to continue, and this function should be called again later the application is waiting for an asynchronous process to complete, and this function should be called again later
241
242
This function may NOT write to the TCP buffer. Internal See documentation in the TCP/IP Stack API or HTTP2.h for details. Preconditions None Parameters Parameters cFile Return Values Return Values <= 0x79 >= 0x80 Description valid authentication is required access is granted for this connection Description the name of the file being requested
This function may service multiple HTTP requests simultaneously, especially when managing its output state. Exercise caution when using global or static variables inside this routine. Use curHTTP.callbackPos or curHTTP.data for storage associated with individual requests. Preconditions None Parameters Parameters wParam1 wParam2 ... Description first parameter passed in the dynamic variable (if any) second parameter passed in the dynamic variable (if any) additional parameters as necessary
244
245
Reads a value from a URL encoded string in the TCP buffer. This function is meant to be called from an HTTPExecutePost ( see page 240) callback to facilitate easier parsing of incoming data. This function also prevents buffer overflows by forcing the programmer to indicate how many bytes are expected. At least 2 extra bytes are needed in cData above the maximum length of data expected to be read. This function will read until the next '&' character, which indicates the end of a value parameter. It assumes that the front of the buffer is the beginning of the value paramter to be read. If curHTTP.byteCount indicates that all expected bytes are in the buffer, it assumes that all remaining data is the value and acts accordingly. This function properly updates curHTTP.byteCount by decrementing it by the number of bytes read. The terminating '&' character is also removed from the buffer. Preconditions Front of TCP buffer is the beginning of a name parameter, and the rest of the TCP buffer contains a URL-encoded string with a name parameter terminated by a '=' character. Parameters Parameters cData wLen Return Values Return Values HTTP_READ_OK HTTP_READ_TRUNCTATED HTTP_READ_INCOMPLETE Description value was successfully read entire value could not fit in the buffer, so the value was truncated and data has been lost entire value was not yet in the buffer, so call this function again later to retrieve Description where to store the value once it is read how many bytes can be written to cData
246
247
see page
HTTPHeaderParseContentLength Parses the "Content-Length:" header for a request. ( see page 254) HTTPHeaderParseCookie ( page 254) HTTPHeaderParseLookup ( page 255) HTTPIncFile ( HTTPLoadConn ( see Parses the "Cookie:" headers for a request and stores them as GET variables. see Calls the appropriate header parser based on the index of the header that was read from the request. Writes a file byte-for-byte to the currently loaded TCP socket. Saves a file uploaded via POST as the new MPFS image in EEPROM or external Flash. Performs any pending operations for the currently loaded HTTP connection. Reads to a buffer until a specified delimiter character.
see page 256) Switches the currently loaded connection for the HTTP2 module.
248
Serves up the next chunk of curHTTP ( see page 237)'s file, up to a) available TX FIFO space or b) the next callback index, whichever comes first.
Macros Name HTTP_CACHE_LEN ( page 250) see Description Max lifetime (sec) of static responses as string Define the maximum data length for reading cookie and GET/POST arguments (bytes) Set to length of longest string above
HTTP_MIN_CALLBACK_FREE Define the minimum number of bytes free in the TX FIFO before executing ( see page 251) callbacks HTTP_PORT ( see page 251) Define the listening port for the HTTP server see page Max time (sec) to await more data before timing out and disconnecting the socket Define the listening port for the HTTPS server (if STACK_USE_SSL_SERVER is enabled) Access the current state machine HTTP_TIMEOUT ( 253) HTTPS_PORT ( 258) smHTTP (
see page
RESERVED_HTTP_MEMORY Macro indicating how much RAM to allocate on an ethernet controller to store ( see page 260) HTTP state data. Module HTTP2 Server ( Structures Name HTTP_STUB ( 252) Variables Name curHTTPID ( httpContentTypes ( page 253) httpFileExtensions ( page 253) see see Header strings for which we'd like to parse Initial response strings (Corresponding to HTTP_STATUS ( HTTP stubs with state machine and socket see page 251)) Description see page 249) ID of the currently loaded HTTP_CONN ( see page 237) see page 250) Content-type strings corresponding to HTTP_FILE_TYPE ( see page Description HTTP Connection Struct Stores partial state data for each connection Meant for storage in fast access RAM see page 227)
HTTPRequestHeaders ( see page 258) HTTPResponseHeaders ( see page 258) httpStubs ( Description see page 259)
The following functions and variables are designated as internal to the HTTP2 module.
249
250
251
10.8 HTTP2 Server C typedef enum { HTTP_GET = 0u, HTTP_POST, HTTP_BAD_REQUEST, HTTP_UNAUTHORIZED, HTTP_NOT_FOUND, HTTP_OVERFLOW, HTTP_INTERNAL_SERVER_ERROR, HTTP_NOT_IMPLEMENTED, HTTP_MPFS_FORM, HTTP_MPFS_UP, HTTP_MPFS_OK, HTTP_MPFS_ERROR, HTTP_REDIRECT, HTTP_SSL_REQUIRED } HTTP_STATUS; Members Members HTTP_GET = 0u HTTP_POST HTTP_BAD_REQUEST HTTP_UNAUTHORIZED HTTP_NOT_FOUND HTTP_OVERFLOW HTTP_INTERNAL_SERVER_ERROR HTTP_NOT_IMPLEMENTED HTTP_MPFS_FORM HTTP_MPFS_UP HTTP_MPFS_OK HTTP_MPFS_ERROR HTTP_REDIRECT HTTP_SSL_REQUIRED Description
Description GET command is being processed POST command is being processed 400 Bad Request will be returned 401 Unauthorized will be returned 404 Not Found will be returned 414 Request-URI Too Long will be returned 500 Internal Server Error will be returned 501 Not Implemented (not a GET or POST command) Show the MPFS Upload form An MPFS Upload is being processed An MPFS Upload was successful An MPFS Upload was not a valid image 302 Redirect will be returned 403 Forbidden is returned, indicating SSL is required
253
Parses the "Authorization:" header for a request. For example, "BASIC YWRtaW46cGFzc3dvcmQ=" is decoded to a user name of "admin" and a password of "password". Once read, HTTPCheckAuth ( see page 238) is called from CustomHTTPApp.c to determine if the credentials are acceptable. The return value of HTTPCheckAuth ( Remarks This function is ony available when HTTP_USE_AUTHENTICATION is defined. Preconditions None see page 238) is saved in curHTTP.isAuthorized for later use by the application.
10.8 HTTP2 Server the rest. Preconditions None Parameters Parameters cFile
256
257
10.8 HTTP2 Server Return Values Return Values HTTP_READ_OK HTTP_READ_TRUNCTATED HTTP_READ_INCOMPLETE
Description data was successfully read entire data could not fit in the buffer, so the data was truncated and data has been lost delimiter character was not found
258
Define the listening port for the HTTPS server (if STACK_USE_SSL_SERVER is enabled)
10.9 ICMP SM_HTTP_DISCONNECT } SM_HTTP2; Members Members SM_HTTP_IDLE = 0u SM_HTTP_PARSE_REQUEST SM_HTTP_PARSE_HEADERS SM_HTTP_AUTHENTICATE SM_HTTP_PROCESS_GET SM_HTTP_PROCESS_POST SM_HTTP_PROCESS_REQUEST SM_HTTP_SERVE_HEADERS SM_HTTP_SERVE_COOKIES SM_HTTP_SERVE_BODY SM_HTTP_SEND_FROM_CALLBACK SM_HTTP_DISCONNECT Description Basic HTTP Connection State Machine
Description Socket is idle Parses the first line for a file name and GET args Reads and parses headers one at a time Validates the current authorization state Invokes user callback for GET args or cookies Invokes user callback for POSTed data Begins the process of returning data Sends any required headers for the response Adds any cookies to the response Serves the actual content Invokes a dynamic variable callback Disconnects the server and closes all files
10.9 ICMP
The Internet Control Message Protocol is used to send error and status messages and requests. The ICMP module implements the Echo Reply message type (commonly referred to as a ping) which can be used to determine if a specified host is reachable across an IP network from a device running the TCP/IP stack. An ICMP server is also supported to respond to pings from other devices.
260
10.9 ICMP
see page
ICMPSendPingToHost ( see page 262) ICMPSendPingToHostROM ( see page 263) ICMPGetReply ( 263) ICMPEndUsage ( 264) Macros Name ICMPSendPingToHostROM ( see page 264) Module ICMP ( see page 260) see page
Description The following functions and variables are accessible or implemented by the stack application.
261
10.9 ICMP Description Claims ownership of the ICMP module. Remarks None Preconditions None
262
10.9 ICMP Description None Remarks None Preconditions ICMPBeginUsage ( Parameters Parameters szRemoteHost
Description Host name to ping. Must be stored in RAM if being called by PIC18. Ex. www.microchip.com
263
-3: Could not resolve hostname (DNS timeout or hostname invalid) -2: No response received yet -1: Operation timed out (longer than ICMP_TIMEOUT ( see page 267)) has elapsed. >=0: Number of TICKs that elapsed between initial ICMP transmission and reception of a valid echo. Description None Remarks None Preconditions ICMPBeginUsage ( see page 261)() returned TRUE and ICMPSendPing ( see page 262)() was called
264
10.9 ICMP
The following functions and variables are designated as internal to the ICMP module.
10.9 ICMP Remarks None Preconditions MAC buffer contains ICMP type packet. Parameters Parameters *remote len
Description Pointer to a NODE_INFO structure of the ping requester Count of how many bytes the ping header and payload are in this IP packet
10.9 ICMP C enum { SM_IDLE = 0, SM_DNS_SEND_QUERY, SM_DNS_GET_RESPONSE, SM_ARP_SEND_QUERY, SM_ARP_GET_RESPONSE, SM_ICMP_SEND_ECHO_REQUEST, SM_ICMP_GET_ECHO_RESPONSE } ICMPState; Description ICMP State Machine Enumeration
267
10.10 MPFS2
10.10 MPFS2
The MPFS2 file system module provides a light-weight read-only file system that can be stored in external EEPROM, external serial Flash, or internal Flash program memory. This file system serves as the basis for the HTTP2 web server module, but is also used by the SNMP module and is available to other applications that require basic read-only storage capabilities. The MPFS2 module includes an MPFS2 Utility that runs on your PC. This program builds MPFS2 images in various formats for use in the supported storage mediums. More information is available in the MPFS2 Utility ( see page 59) section. Using External Storage For external storage, the MPFS2 file system supports Microchip 25LCxxx EEPROM parts for densities up to 1Mbit. SST 25VFxxxB serial Flash parts are also supported for densities up to 32Mbit. To use external EEPROM storage, ensure that the configuration macro MPFS_USE_EEPROM is defined in TCPIPConfig.h. If you are using a 1Mbit part (25LC1024), also be sure to define USE_EEPROM_25LC1024 to enable the 24-bit device addressing used by that part. For external serial Flash, define MFPS_USE_SPI_FLASH instead of the EEPROM macros. Images stored externally are uploaded via HTTP. This can be accomplished using the MPFS2 Utility, or can be accessed directly from a browser. Uploading files directly ( see page 60) is described in the MPFS2 Utility documentation. Uploading images via HTTP can be accomplished as described in the Getting Started ( see page 74) section. When storing images externally, space can be reserved for separate application use. The configuration macro MPFS_RESERVE_BLOCK controls the size of this space. The specified number of bytes will be reserved at the beginning address of the storage device (0x000000). When using serial Flash, this address must be a multiple of the flash sector size (4096 bytes). Using Internal Flash Storage When storing images in internal Flash program memory, new images cannot be uploaded at run time. Instead, the image is compiled in as part of your project in the MPLAB IDE. To select this storage option comment out the configuration macro MPFS_USE_EEPROM in TCPIPConfig.h, then ensure that the image file generated by the MPFS2 Utility is included in the MPLAB project. Other Considerations MPFS2 defines a fixed number of files that can be opened simultaneously. The configuration parameter MAX_MPFS_HANDLES controls how many files can be opened at once. If this resource is depleted, no new files can be opened until MPFSClose ( see page 271) is called for an existing handle. The HTTP2 web server expects to be able to use at least two handles for each connection, plus one extra. Additional handles should be allocated if other modules will be accessing the file system as well.
268
10.10 MPFS2
MPFSGetBytesRem ( page 273) MPFSGetEndAddr ( page 273) MPFSGetFilename ( page 274) MPFSGetFlags ( 274) MPFSGetID ( MPFSGetLong ( 275)
see page
see page 275) Determines the ID in the FAT for a file. see page see see Reads a DWORD or Long value from the MPFS. Reads the microtime portion of a file's timestamp. Determines the current position in the file Reads the size of a file. Reads the starting address of a file. Reads the timestamp for the specified file.
see page 278) Opens a file in the MPFS2 file system. see page see see page Quickly re-opens a file. Opens a file in the MPFS2 file system. Writes an array of data to the MPFS image.
MPFSOpenROM ( page 279) MPFSPutArray ( 279) MPFSSeek ( MPFSPutEnd ( 280) Macros Name MPFS_INVALID ( 270)
see page 280) Moves the current read pointer to a new location. see page Finalizes an MPFS writing operation.
269
10.10 MPFS2 MPFS_INVALID_HANDLE ( see page 270) Module MPFS2 ( Types Name MPFS_HANDLE ( 270) Description see page 268)
The following functions and variables are accessible by the stack application.
270
10.10 MPFS2 C typedef enum { MPFS_SEEK_START = 0u, MPFS_SEEK_END, MPFS_SEEK_FORWARD, MPFS_SEEK_REWIND } MPFS_SEEK_MODE; Members Members MPFS_SEEK_START = 0u MPFS_SEEK_END MPFS_SEEK_FORWARD MPFS_SEEK_REWIND Description Indicates the method for MPFSSeek (
Description Seek forwards from the front of the file Seek backwards from the end of the file Seek forward from the current position See backwards from the current position
In order to prevent misreads, the MPFS will be inaccessible until MPFSClose ( available when the MPFS is stored in internal Flash program memory. Preconditions None
10.10 MPFS2 Parameters Parameters hMPFS ( cData wLen see page 338)
Description the file handle from which to read where to store the bytes that were read how many bytes to read
273
10.10 MPFS2
274
10.10 MPFS2
275
10.10 MPFS2
10.10 MPFS2 C DWORD MPFSGetSize( MPFS_HANDLE hMPFS ); Returns The size that was read as a DWORD Description Reads the size of a file. Preconditions
The file handle referenced by hMPFS is already open. Parameters Parameters hMPFS ( see page 338) Description the file handle from which to read the metadata
The file handle referenced by hMPFS is already open. Parameters Parameters hMPFS ( see page 338) Description the file handle from which to read the metadata
10.10 MPFS2
279
Microchip TCP/IP Stack Help the array of bytes to write how many bytes to write
280
10.10 MPFS2
281
10.10 MPFS2 Macros Name MAX_FILE_NAME_LEN ( see page 283) MPFS_WRITE_PAGE_SIZE ( see page 284) MPFS2_FLAG_HASINDEX ( see page 284) MPFS2_FLAG_ISZIPPED ( see page 284) MPFSTell ( see page 285) MPFS_INVALID_FAT ( page 287) Module MPFS2 ( Structures Name MPFS_STUB ( 283) see page see page 268)
Description Supports long file names to 64 characters Defines the size of a page in EEPROM Indicates a file has an associated index of dynamic variables Indicates a file is compressed with GZIP compression Alias of MPFSGetPosition ( see page 276)
Description Stores each file handle's information Handles are free when addr = MPFS_INVALID ( see page 270) Stores the data for an MPFS2 FAT record
MPFS_FAT_RECORD ( see page 286) Types Name MPFS_PTR ( Variables Name isMPFSLocked ( 282) lastRead ( see page
Description Allows the MPFS to be locked, preventing access during updates Track the last read address to prevent unnecessary data overhead to switch locations.
see page 284) Track the MPFS File Handles MPFSStubs[0] is reserved for internal use (FAT access) FAT record cache see page 286) Number of files in this MPFS image see page 287) ID of currently loaded fatCache (
The following functions and variables are designated as internal to the MPFS2 module.
282
10.10 MPFS2
283
Stores each file handle's information Handles are free when addr = MPFS_INVALID (
284
10.10 MPFS2
285
10.10 MPFS2
286
10.11 NBNS
The NetBIOS Name Service protocol associates host names with IP addresses, similarly to DNS, but on the same IP subnet. Practically, this allows the assignment of human-name hostnames to access boards on the same subnet. For example. in the "TCPIP Demo App" demonstration project, the demo board is programmed with the human name 'mchpboard' so it can be accessed directly instead of with its IP address.
287
10.11 NBNS
Description Pointer to an array into which a received NetBIOS name should be copied.
290
10.12 Performance Tests Module Performance Tests ( Description see page 290)
The following functions and variables are public, but are intended only to be accessed by the stack itself. Applications should generally not call these functions or modify these variables.
291
RX_PERFORMANCE_PORT The TCP port to listen ( ( see page 293) TX_PERFORMANCE_PORT The TCP port to listen ( ( see page 294) Module Performance Tests ( Description see page 290)
The following functions and variables are designated as internal to the module.
292
293
294
First, call SMTPBeginUsage ( see page 300) to verify that the SMTP client is available and to begin a new message. If FALSE is returned, the SMTP client is busy and the application must return to the main loop to allow StackTask to execute again. Next, set the local relay server to use as SMTPClient.Server. If the local relay server requires a user name and password, set SMTPClient.Username and SMTPClient.Password to the appropriate credentials. If server parameters are not set, the stack will attempt to deliver the message directly to its destination host. This will likely fail due to spam prevention measures put in place by most ISPs and network administrators. Continue on to set the header strings as necessary for the message. This includes the subject line, from address, and any recipients you need to add. Finally, set SMTPClient.Body to the message to be sent. At this point, verify that SMTPClient.ROMPointers is correctly configured for any strings that are stored in program memory. Once the message is ready to send, call SMTPSendMail ( see page 306) to instruct the SMTP client to begin transmission. The application must now call SMTPIsBusy ( see page 302) until it returns FALSE. Each time TRUE is returned, return to the main loop and wait for StackTask to execute again. This allows the SMTP server to continue its work in a cooperative multitasking manner. Once FALSE is returned, call SMTPEndUsage ( see page 301) to release the SMTP client. Check the return value of this function to determine if the message was successfully sent. The example in MainDemo.c needs minor modifications to use your e-mail address. The Server and To fields must be set in SMTPDemo ( see page 94) in order for the message to be properly delivered. Once this is done, holding down BUTTON2 and BUTTON3 simultaneously (the left-most two buttons) will begin sending the message. LED1 will light as the message is being processed, and will extinguish when the SMTP state machine completes. If the transmission was successful LED2 will light, otherwise it will remain dark.
295
The first stage is largely similar to the first few steps in sending a short message. First, call SMTPBeginUsage ( see page 300) to verify that the SMTP client is available and to begin a new message. If FALSE is returned, the SMTP client is busy and the application must return to the main loop to allow StackTask to execute again. Next, set the local relay server to use as SMTPClient.Server. If the local relay server requires a user name and password, set SMTPClient.Username and SMTPClient.Password to the appropriate credentials. If server parameters are not set, the stack will attempt to deliver the message directly to its destination host. This will likely fail due to spam prevention measures put in place by most ISPs and network administrators. Continue on to set the header strings as necessary for the message. This includes the subject line, from address, and any recipients you need to add. The next portion of the process differs. Ensure that SMTPClient.Body remains set to its default (NULL). At this point, call SMTPSendMail ( see page 306) to open a connection to the remote server and transmit the headers. The application is now ready to proceed to the second stage and send the message body. The following diagram provides an overview of stage two and three:
Upon entering stage two, the application should call SMTPIsBusy ( see page 302) to verify that the connection to the remote server is active and has not been lost. If the call succeeds, call SMTPIsPutReady ( see page 302) to determine how many bytes are available in the TX buffer. If no bytes are available, return to the main loop so that StackTask can transmit the data to the remote node and free up the buffer. If space is available, any combination of the SMTPPut ( see page 303), SMTPPutArray ( see page 303), SMTPPutROMArray ( see page 304), SMTPPutString ( see page 305), and SMTPPutROMString ( see page 305) functions may be called to transmit the message. These functions return the number of bytes successfully written. Use this value, along with the value originally returned from SMTPIsPutReady ( see page 302) to track how much free space 296
The SMTP client module can accept ( see page 166) as much data as the TCP TX FIFO can hold. This is determined by the socket initializer for TCP_PURPOSE_DEFAULT type sockets in TCPIPConfig.h, which defaults to 200 bytes. If the TX buffer is exhausted before the message is complete, return to the main loop so that StackTask may transmit the data to the remote node and free up the buffer. Upon return, go to the beginning of the second stage to transmit the next portion of the message. Once the message is complete, the application will move to the third stage. Call SMTPPutDone ( see page 304) to inform the SMTP client that no more data remains. Then call SMTPIsBusy ( see page 302) repeatedly. Each time TRUE is returned, return to the main loop and wait for StackTask to execute again. Once FALSE is returned, the message transmission has completed and the application must call SMTPEndUsage ( see page 301) to release the SMTP client. Check the return value of this function to determine if the message was successfully sent. The example in MainDemo.c needs minor modifications to use your e-mail address. Set the Server and To fields in SMTPDemo ( see page 94), and ensure that these fields are being properly assigned to SMTPClient ( see page 301) struct. The demo works exactly the same way as the previous one, with BUTTON2 and BUTTON3 held down simultaneously (the left-most two buttons) kicking off the state machine. LED1 will light as the message is being processed, and will extinguish when the SMTP state machine completes. If the transmission was successful LED2 will light, otherwise it will remain dark.
see page 301) Flushes the SMTP socket and forces all data to be sent. see page see Determines if the SMTP client is busy. Determines how much data can be written to the SMTP client. Writes a single byte to the SMTP client. Writes a series of bytes to the SMTP client. Indicates that the on-the-fly message is complete. Writes a series of bytes from ROM to the SMTP client. Writes a string from ROM to the SMTP client. Writes a string to the SMTP client. Initializes the message sending process.
SMTPPutROMArray ( page 304) SMTPPutROMString ( page 305) SMTPPutString ( 305) SMTPSendMail ( 306) Macros Name
297
10.13 SMTP Client SMTP_RESOLVE_ERROR ( see page 300) SMTP_SUCCESS ( page 300) Module SMTP Client ( Structures Name SMTP_POINTERS ( page 298) Variables Name SMTPClient ( Description see page 301) see see page 294) see
Microchip TCP/IP Stack Help DNS lookup for SMTP server failed Message was successfully sent
Description
The following functions and variables are available to the stack application.
union { BYTE * szRAM; ROM BYTE * szROM; } BCC; union { BYTE * szRAM; ROM BYTE * szROM; } From; union { BYTE * szRAM; ROM BYTE * szROM; } Subject; union { BYTE * szRAM; ROM BYTE * szROM; } OtherHeaders; union { BYTE * szRAM; ROM BYTE * szROM; } Body; struct { unsigned char Server : 1; unsigned char Username : 1; unsigned char Password : 1; unsigned char To : 1; unsigned char CC : 1; unsigned char BCC : 1; unsigned char From : 1; unsigned char Subject : 1; unsigned char OtherHeaders : 1; unsigned char Body : 1; } ROMPointers; BOOL UseSSL; WORD ServerPort; } SMTP_POINTERS; Description This structure of pointers configures the SMTP Client to send an e-mail message. Initially, all pointers will be null. Set SMTPClient ( see page 301).[field name].szRAM to use a string stored in RAM, or SMTPClient ( see page 301).[field name].szROM to use a string stored in ROM. (Where [field name] is one of the parameters below.) If a ROM string is specified, SMTPClient.ROMPointers.[field name] must also be set to 1 to indicate that this field should be retrieved from ROM instead of RAM. Remarks When formatting an e-mail address, the SMTP standard format for associating a printable name may be used. This format places the printable name in quotation marks, with the address following in pointed brackets, such as "John Smith" <john.smith@domain.com> Parameters Parameters Server Username Password To CC BCC From Subject Description the SMTP server to relay the message through the user name to use when logging into the SMTP server, if any is required the password to supply when logging in, if any is required the destination address for this message. May be a comma-separated list of addresss, and/or formatted. The CC addresses for this message, if any. May be a comma-separated list of addresss, and/or formatted. The BCC addresses for this message, if any. May be a comma-separated list of addresss, and/or formatted. The From address for this message. May be formatted. The Subject header for this message.
299
10.13 SMTP Client OtherHeaders Body ROMPointers UseSSL ServerPort ( see page 96)
Any additional headers for this message. Each additional header, including the last one, must be terminated with a CRLF pair. When sending a message from memory, the location of the body of this message in memory. Leave as NULL to build a message on-the-fly. Indicates which parameters to read from ROM instead of RAM. When STACK_USE_SSL_CLIENT is enabled, this flag causes the SMTP client to make an SSL connection to the server. (WORD value) Indicates the port on which to connect ( remote SMTP server. see page 168) to the
The SMTP module is in use by another application. Call SMTPBeginUsage again later, after returning to the main program loop
************************************************************************ The global set of SMTP_POINTERS. Set these parameters after calling SMTPBeginUsage successfully.
301
Flushes the SMTP socket and forces all data to be sent. Remarks This function should only be called externally when the SMTP client is generating an on-the-fly message. (That is, SMTPSendMail ( see page 306) was called with SMTPClient.Body set to NULL.) Preconditions SMTPBeginUsage ( see page 300) returned TRUE on a previous call.
302
This function should only be called externally when the SMTP client is generating an on-the-fly message. (That is, SMTPSendMail ( see page 306) was called with SMTPClient.Body set to NULL.) Preconditions SMTPBeginUsage ( see page 300) returned TRUE on a previous call, and an on-the-fly message is being generated. This requires that SMTPSendMail ( see page 306) was called with SMTPClient.Body set to NULL.
303
This function should only be called externally when the SMTP client is generating an on-the-fly message. (That is, SMTPSendMail ( see page 306) was called with SMTPClient.Body set to NULL.) Internal SMTPPut ( see page 303) must be used instead of TCPPutArray ( replaced by "rn..". Preconditions SMTPBeginUsage ( Parameters Parameters Data Len Description The data to be written How many bytes should be written see page 300) returned TRUE on a previous call. see page 458) because "rn." must be transparently
304
SMTPPut ( see page 303) must be used instead of TCPPutArray ( replaced by "rn..". Preconditions SMTPBeginUsage ( Parameters Parameters Data Len Description The data to be written see page 300) returned TRUE on a previous call.
The number of bytes written. If less than the length of Data, then the TX FIFO became full before all bytes could be written. Description Writes a string to the SMTP client. Remarks This function should only be called externally when the SMTP client is generating an on-the-fly message. (That is, SMTPSendMail ( see page 306) was called with SMTPClient.Body set to NULL.) Internal SMTPPut ( see page 303) must be used instead of TCPPutString ( replaced by "rn..". Preconditions SMTPBeginUsage ( Parameters Parameters Data Description The data to be written see page 300) returned TRUE on a previous call. see page 460) because "rn." must be transparently
306
SMTP_SERVER_REPLY_TIMEOUT How long to wait before assuming the connection has been dropped ( see page 311) (default 8 seconds) Module SMTP Client ( Variables Name CRPeriod ( MySocket ( see page 308) see page 309) see see page see page Description State machine for the CR LF Period replacement Used by SMTPPut ( page 303) to transparently replace "rn." with "rn.." Socket currently in use by the SMTP client State machine for writing the SMTP message headers Response code from server when an error exists State machine for parsing incoming responses see see page 294)
307
10.13 SMTP Client SMTPFlags ( SMTPServer ( 311) SMTPState ( TransportState ( 313) Description
Microchip TCP/IP Stack Help see page 311) Internal flags used by the SMTP Client see page IP address of the remote SMTP server
see page 312) Message state machine for the SMTP Client see page State of the transport for the SMTP Client
The following functions and variables are designated for internal use by the SMTP Client module.
308
10.13 SMTP Client Preconditions SMTPBeginUsage ( Parameters Parameters str wLen Section SMTP Client Internal Function Prototypes
Description The string in which to search for an e-mail address the length of str
309
10.13 SMTP Client C enum { PUTHEADERS_FROM_INIT = 0, PUTHEADERS_FROM, PUTHEADERS_TO_INIT, PUTHEADERS_TO, PUTHEADERS_CC_INIT, PUTHEADERS_CC, PUTHEADERS_SUBJECT_INIT, PUTHEADERS_SUBJECT, PUTHEADERS_OTHER_INIT, PUTHEADERS_OTHER, PUTHEADERS_DONE } PutHeadersState; Members Members PUTHEADERS_FROM_INIT = 0 PUTHEADERS_FROM PUTHEADERS_TO_INIT PUTHEADERS_TO PUTHEADERS_CC_INIT PUTHEADERS_CC PUTHEADERS_SUBJECT_INIT PUTHEADERS_SUBJECT PUTHEADERS_OTHER_INIT PUTHEADERS_OTHER PUTHEADERS_DONE Description
Description Preparing to send From header Sending From header Preparing to send To header Sending To header Preparing to send CC header Sending CC header Preparing to send Subject header Sending Subject header Preparing to send additional headers Sending additional headers Done writing all headers
10.13 SMTP Client } RXParserState; Description State machine for parsing incoming responses
311
10.13 SMTP Client C IP_ADDR SMTPServer; Description IP address of the remote SMTP server
10.14 Reboot SMTP_RCPTTO SMTP_RCPTTO_ACK SMTP_RCPTTO_ISDONE SMTP_RCPTTOCC_INIT SMTP_RCPTTOCC SMTP_RCPTTOCC_ACK SMTP_RCPTTOCC_ISDONE SMTP_RCPTTOBCC_INIT SMTP_RCPTTOBCC SMTP_RCPTTOBCC_ACK SMTP_RCPTTOBCC_ISDONE SMTP_DATA SMTP_DATA_ACK SMTP_DATA_HEADER SMTP_DATA_BODY_INIT SMTP_DATA_BODY SMTP_DATA_BODY_ACK SMTP_QUIT_INIT SMTP_QUIT Description Message state machine for the SMTP Client
Microchip TCP/IP Stack Help Sending RCPT TO command RCPT TO was accepted Done sending RCPT TO commands Preparing to send RCPT TO CC commands Sending RCPT TO CC commands RCPT TO CC was accepted Done sending RCPT TO CC Preparing to send RCPT TO BCC commands Sending RCPT TO BCC commands RCPT TO BCC was accepted Done sending RCPT TO BCC Sending DATA command DATA command accpted Sending message headers Preparing for message body Sending message body Message body accepted Sending QUIT command QUIT accepted, connection closing
313
10.14 Reboot
10.14 Reboot
The Reboot module will allow a user to remotely reboot the PIC microcontroller that is running the TCP/IP stack. This feature is primarily used for bootloader applications, which must reset the microcontroller to enter the bootloader code section. This module will execute a task that listens on a specified UDP port for a packet, and then reboots if it receives one. The port can be configured in Reboot.c with the following macro: #define REBOOT_PORT 69
For improved security, you can limit reboot capabilities to users on the same subnet by specifying the following macro in Reboot.c: #define REBOOT_SAME_SUBNET_ONLY
REBOOT_SAME_SUBNET_ONLY For improved security, you might want to limit reboot capabilities to only ( see page 315) users on the same IP subnet. Define REBOOT_SAME_SUBNET_ONLY to enable this access restriction. Module Reboot ( Description The following functions and variables are public, but are intended only to be accessed by the stack itself. Applications should generally not call these functions or modify these variables. see page 314)
This module is primarily for use with the Ethernet bootloader. By resetting, the Ethernet bootloader can take control for a second and let a firmware upgrade take place. Preconditions Stack is initialized()
10.15 SNMP
Functions Name getSnmpV2GenTrapOid ( ProcessGetBulkVar ( ProcessGetNextVar ( ProcessGetVar ( Description see page 359) Resolves generic trap code to generic trap OID. This is function ProcessGetBulkVar. This is function ProcessGetNextVar. This is function ProcessGetVar. This is function ProcessSnmpv3MsgData. To search for exact index node in case of a Sequence variable.
SNMPIdRecrdValidation (
see page 361) Used to Restrict the access dynamic and non dynamic OID string for A perticular SNMP Version.
315
Microchip TCP/IP Stack Help see page 362) Validates the set variable data length to data type. This is function Snmpv3AESDecryptRxedScopedPdu. This is function Snmpv3BufferPut. This is function Snmpv3FormulateEngineID. This is function Snmpv3GetAuthEngineTime. This is function Snmpv3GetBufferData. This is function Snmpv3InitializeUserDataBase.
Snmpv3AESDecryptRxedScopedPdu ( see page 362) Snmpv3BufferPut ( see page 362) see page see page Snmpv3FormulateEngineID ( 363) Snmpv3GetAuthEngineTime ( 363) Snmpv3GetBufferData (
Snmpv3MsgProcessingModelProcessPDU This is function Snmpv3MsgProcessingModelProcessPDU. ( see page 364) Snmpv3Notify ( see page 364) see This is function Snmpv3Notify. This is function Snmpv3ScopedPduProcessing. Snmpv3ScopedPduProcessing ( page 364) Snmpv3TrapScopedpdu (
see page 364) This is function Snmpv3TrapScopedpdu. This is function Snmpv3UserSecurityModelProcessPDU. This is function Snmpv3UsmAesEncryptDecryptInitVector. This is function Snmpv3UsmOutMsgAuthenticationParam. This is function Snmpv3ValidateEngineId. This is function Snmpv3ValidateSecNameAndSecLvl. This is function Snmpv3ValidateSecurityName.
Snmpv3UserSecurityModelProcessPDU ( see page 365) Snmpv3UsmAesEncryptDecryptInitVector ( see page 365) Snmpv3UsmOutMsgAuthenticationParam ( see page 365) Snmpv3ValidateEngineId ( 365) see page
Snmpv3ValidateSecNameAndSecLvl ( see page 366) Snmpv3ValidateSecurityName ( page 366) Macros Name see
Description
IS_SNMPV3_AUTH_STRUCTURE This is macro IS_SNMPV3_AUTH_STRUCTURE. ( see page 369) REPORT_RESPONSE ( page 369) SNMP_MAX_MSG_SIZE ( page 370) see see This is macro REPORT_RESPONSE. SNMP MIN and MAX message 484 bytes in size As per RFC 3411 snmpEngineMaxMessageSize and RFC 1157 ( section 4- protocol specification ) and implementation supports more than 484 whenever feasible. This is macro SNMP_V3.
316
Description see page 368) This variable is used for gext next request for zero instance This is variable gSNMPv3ScopedPduDataPos. This is variable gSNMPv3ScopedPduRequestBuf.
gSNMPv3ScopedPduResponseBuf This is variable gSNMPv3ScopedPduResponseBuf. ( see page 368) msgSecrtyParamLenOffset ( page 369) Description Simple Network Management Protocol V2c (community) agent implementation of RFC 3416. see This is variable msgSecrtyParamLenOffset.
VENDOR_SPECIFIC_TRAP_NOTIFICATION_TYPE This is type ( see page 319) VENDOR_SPECIFIC_TRAP_NOTIFICATION_TYPE. SNMP_ACTION ( see page 319) This is the list of SNMP action a remote NMS can perform. This inforamtion is passed to application via callback SNMPValidateCommunity ( see page 323)(). Application should validate the action for given community string. This is type COMMUNITY_TYPE.
Description see page Prepare, validate remote node which will receive trap and send trap pdu. This is function SNMPValidateCommunity. Creates and Sends TRAP pdu. This routine Set the mib variable with the requested value. Used to Get/collect OID variable information. Resolves given remoteHost IP address into MAC address. Collects trap notification info and send ARP to remote host. To search for next index node in case of a Sequence variable.
SNMPValidateCommunity ( see page 323) SNMPNotify ( 323) SNMPSetVar ( 324) SNMPGetVar ( 325) see page see page see page see see see
317
Description
SNMP_COMMUNITY_MAX_LEN This is the maximum length for community string. Application must ensure ( see page 328) that this length is observed. SNMP module adds one byte extra after SNMP_COMMUNITY_MAX_LEN for adding '0' NULL character. OID_MAX_LEN ( see page 328) Change this to match your OID string length. see This is macro SNMP_START_OF_VAR. This is macro SNMP_END_OF_VAR. This is macro SNMP_INDEX_INVALID. Trap information. This table maintains list of intereseted receivers who should receive notifications when some interesting event occurs. SNMP_START_OF_VAR ( page 328) SNMP_END_OF_VAR ( page 328) SNMP_INDEX_INVALID ( page 329) TRAP_TABLE_SIZE ( page 329) see
see see
TRAP_COMMUNITY_MAX_LEN This is macro TRAP_COMMUNITY_MAX_LEN. ( see page 329) NOTIFY_COMMUNITY_LEN ( see page 329) Module SNMP ( Structures Name TRAP_INFO ( 321) Types Name SNMP_ID ( see page 327) Description This is the SNMP OID variable id. This id is assigned via MIB file. Only dynamic and AgentID variables can contian ID. MIB2BIB utility enforces this rules when BIB was generated. This is type SNMP_INDEX. see page Description This is type TRAP_INFO. see page 315) This is macro NOTIFY_COMMUNITY_LEN.
see page
Description see page see global flag to send Trap #if defined(SNMP_STACK_USE_V2_TRAP) || defined(SNMP_V1_V2_TRAP_WITH_SNMPV3) //if gSetTrapSendFlag == FALSE then the last varbind variable for //multiple varbind variable pdu structure or if there is only varbind variable send. // if gSetTrapSendFlag == TRUE, then v2 trap pdu is expecting more varbind variable. BYTE gSetTrapSendFlag = FALSE; #endif Global flag for Generic trap notification Vendor specific trap code
gOIDCorrespondingSnmpMibID Gloabal var to store SNMP ID of var for OID received in SNMP request. ( see page 322)
318
The following functions and variables are available to the stack application.
319
10.15 SNMP Members Members SNMP_GET = 0xa0 SNMP_GET_NEXT = 0xa1 SNMP_GET_RESPONSE = 0xa2 SNMP_SET = 0xa3 SNMP_TRAP = 0xa4 SNMP_V2C_GET_BULK = 0xa5 SNMP_V2_TRAP = 0xa7 SNMP_ACTION_UNKNOWN = 0 Description
Description Snmp GET identifier Snmp GET_NEXT identifier Snmp GET_RESPONSE ( Snmp SET identifier Snmp TRAP identifier Snmp GET_BULK identifier Snmp v2 Trap Identifier Snmp requested action unknown see page 337) identifier
This is the list of SNMP action a remote NMS can perform. This inforamtion is passed to application via callback SNMPValidateCommunity ( see page 323)(). Application should validate the action for given community string.
10.15 SNMP BYTE byte; BYTE v[sizeof(DWORD)]; Description This is type SNMP_VAL.
char Community name array community[TRAP_COMMUNITY_MAX_LEN]; IP_ADDR IPAddress; unsigned int bEnabled : 1; Description This is type TRAP_INFO. IP address to which trap to be sent Trap enabled flag
321
#if defined(SNMP_STACK_USE_V2_TRAP) || defined(SNMP_V1_V2_TRAP_WITH_SNMPV3) //if gSetTrapSendFlag == FALSE then the last varbind variable for //multiple varbind variable pdu structure or if there is only varbind variable send. // if gSetTrapSendFlag == TRUE, then v2 trap pdu is expecting more varbind variable. BYTE gSetTrapSendFlag = FALSE; #endif
322
This function is used to send trap notification to previously configured ip address if trap notification is enabled. There are different trap notification code. The current implementation sends trap for authentication failure (4). Remarks This is a callback function called by the application on certain predefined events. This routine only implemented to send a authentication failure Notification-type macro with PUSH_BUTTON oid stored in MPFS. If the ARP is no resolved i.e. if SNMPIsNotifyReady ( see page 325)() returns FALSE, this routine times out in 5 seconds. This routine should be modified according to event occured and should update corrsponding OID and notification type to the trap pdu. Preconditions If application defined event occurs to send the trap.
10.15 SNMP index Return Values Return Values TRUE FALSE This would fail under following contions 4) Data type of given var is unknown
Index of var. If this var is a single,index would be 0, or else if this var Is a sequence, index could be any value from 0 to 127
Description if SNMP notification was successful sent. This does not guarantee that remoteHost recieved it. Notification sent failed. 1) Given SNMP_BIB_FILE does not exist in MPFS 2) Given var does not exist. 3) Previously given agentID does not exist only possible if MPFS itself was corrupted.
Return Values Return Values TRUE FALSE Description if it is OK to set more byte(s). if otherwise.
324
10.15 SNMP
val
Return Values Return Values TRUE FALSE Description If a value exists for given variable at given index. Otherwise.
This would fail if there were not UDP socket to open. Preconditions SNMPNotifyPrepare ( Parameters Parameters remoteHost Return Values Return Values TRUE FALSE Description If remoteHost IP address is resolved and SNMPNotify ( be called. If remoteHost IP address is not resolved. see page 323) may Description Pointer to remote Host IP address see page 326)() is already called.
326
10.15 SNMP
327
328
10.15 SNMP
329
10.15 SNMP
SNMP_ERR_STATUS ( see page 345) Functions Name _SNMPDuplexInit ( _SNMPGet ( _SNMPPut ( see page 333) This is function _SNMPGet. This is function FindOIDsInRequest. Description
see page 340) This is function GetDataTypeInfo. static BYTE IsValidStructure ( This is function SetErrorStatus. This is function IsValidLength. see page 353)(WORD* dataLen);
SetErrorStatus ( IsValidLength (
GetDataTypeInfo ( GetNextLeaf (
see page 351) This is function GetDataTypeInfo. This is function GetNextLeaf. This is function GetOIDStringByAddr. This function is used only when TRAP is enabled. This is function IsValidCommunity. This is function IsValidInt. This is function IsValidLength.
GetOIDStringByAddr ( 352) GetOIDStringByID ( 352) IsValidCommunity ( 352) IsValidInt ( IsValidLength ( IsValidOID ( IsValidPDU (
see page 353) see page 353) see page 353) static BOOL IsValidInt ( see page 352)(DWORD* val); This is function IsValidStructure.
IsValidStructure ( OIDLookup (
see page 354) see Validates the received udp packet Get/Set request header. Validates the received udp packet Snmp header. This is function ProcessSetVar.
ProcessVariables (
see page 355) This routine processes the snmp request and parallely creates the response pdu.
330
Microchip TCP/IP Stack Help see page 356) This is function ReadMIBRecord.
SNMPCheckIfPvtMibObjRequested ( see page 356) Macros Name _SNMPGetTxOffset ( page 333) _SNMPSetTxOffset ( page 334) see see This is macro AGENT_NOTIFY_PORT. This is macro ASN_INT. This is macro ASN_OID. Description This is macro _SNMPGetTxOffset.
AGENT_NOTIFY_PORT ( see page 334) ASN_INT ( ASN_NULL ( ASN_OID ( see page 334) see page 335)
DATA_TYPE_TABLE_SIZE ( see page 336) GET_BULK_REQUEST ( see page 337) GET_NEXT_REQUEST ( see page 337) GET_REQUEST ( page 337) GET_RESPONSE ( page 337) IS_AGENT_PDU ( page 338) IS_ASN_INT ( 339) IS_ASN_NULL ( 339) see see see This is macro GET_RESPONSE. This is macro IS_AGENT_PDU. This is macro IS_ASN_INT. This is macro IS_ASN_NULL. This is macro IS_GET_NEXT_REQUEST. This is macro IS_GET_REQUEST. This is macro GET_BULK_REQUEST. This is macro GET_NEXT_REQUEST.
IS_GET_NEXT_REQUEST ( see page 339) IS_GET_REQUEST ( page 339) IS_GET_RESPONSE ( page 339) IS_OCTET_STRING ( page 340) IS_OID ( IS_SET_REQUEST ( page 340) IS_STRUCTURE ( page 341) IS_TRAP ( OCTET_STRING ( page 342) SET_REQUEST ( 344) see
see This is macro IS_GET_RESPONSE. see This is macro IS_OCTET_STRING. This is macro IS_OID. This is macro IS_SET_REQUEST.
SNMP_AGENT_PORT ( see page 344) SNMP_BIB_FILE_NAME ( see page 345) This is the file that contains SNMP bib file. File name must contain all upper case letter and must match with what was included in MPFS2 image.
331
10.15 SNMP SNMP_COUNTER32 ( page 345) SNMP_GAUGE32 ( page 346) SNMP_IP_ADDR ( page 346) see
Microchip TCP/IP Stack Help This is macro SNMP_COUNTER32. This is macro SNMP_GAUGE32. This is macro SNMP_IP_ADDR. This is macro SNMP_NMS_PORT. This is macro SNMP_NSAP_ADDR. This is macro SNMP_OPAQUE. This is macro SNMP_TIME_TICKS.
see see
SNMP_TIME_TICKS ( page 348) SNMP_V1 ( SNMP_V2C ( STRUCTURE ( 350) TRAP ( Module SNMP ( Structures Name DATA_TYPE_INFO ( page 336) OID_INFO ( PDU_INFO ( see page 315)
see page 349) see page 349) This is macro SNMP_V2C. see page This is macro TRAP.
Description see
reqVarErrStatus ( 343)
SNMP_NOTIFY_INFO ( see page 347) Unions Name INDEX_INFO ( 338) MIB_INFO ( see page Description
SNMP_STATUS ( 348) Variables Name appendZeroToOID ( page 334) dataTypeTable ( 336) hMPFS (
Description see global flag to modify OID by appending zero ASN format datatype for snmp v1 and v2c MPFS file handler Snmp udp socket notify info for trap vars from req list processing err status
see page
see page
332
10.15 SNMP SNMPRxOffset ( 350) SNMPStatus ( 350) SNMPTxOffset ( 350) trapInfo ( Description see page
Microchip TCP/IP Stack Help Snmp udp buffer rx offset MIB file access status Snmp udp buffer tx offset Initialize trap table with no entries.
The following functions and variables are designated as internal to the SNMP module.
333
Process SNMP request pdus,form response pdus routines static BYTE _SNMPGet(void);
10.15 SNMP
336
10.15 SNMP
337
338
10.15 SNMP
339
10.15 SNMP C
10.15 SNMP
341
10.15 SNMP Members Members unsigned int bIsDistantSibling : 1; unsigned int bIsConstant : 1; unsigned int bIsSequence : 1; unsigned int bIsSibling : 1; unsigned int bIsParent : 1; unsigned int bIsEditable : 1; unsigned int bIsAgentID : 1; unsigned int bIsIDPresent : 1; BYTE Val; Section SNMP object information
Description Object have distant sibling node Object is constant Object is sequence Sibling node flag Node is parent flag Node is editable flag Node have agent id flag Id present flag MIB Obj info as byte value
10.15 SNMP DWORD hData; DWORD hSibling; DWORD hChild; BYTE index; BYTE indexLen; Section SNMP MIB variable object information
Microchip TCP/IP Stack Help Data Sibling info Child info Index of object Index length
343
10.15 SNMP Members Members WORD noSuchObjectErr; WORD noSuchNameErr; WORD noSuchInstanceErr; WORD endOfMibViewErr; Section
Description Var list no such obj errors flags Var list no such name error Var list no such instance error Var list end of mib view error
SNMP reuested variable list error status information. Max variable in a request supported 15
344
10.15 SNMP
10.15 SNMP SNMP_TOO_BIG SNMP_NO_SUCH_NAME SNMP_BAD_VALUE SNMP_READ_ONLY SNMP_GEN_ERR SNMP_NO_ACCESS SNMP_WRONG_TYPE SNMP_WRONG_LENGTH SNMP_WRONG_ENCODING SNMP_WRONG_VALUE SNMP_NO_CREATION SNMP_INCONSISTENT_VAL SNMP_RESOURCE_UNAVAILABE SNMP_COMMIT_FAILED SNMP_UNDO_FAILED SNMP_AUTH_ERROR SNMP_NOT_WRITABLE SNMP_INCONSISTENT_NAME SNMP_NO_SUCH_OBJ = 128 SNMP_NO_SUCH_INSTANCE = 129 SNMP_END_OF_MIB_VIEW = 130 Section SNMP specific errors
Microchip TCP/IP Stack Help Value too big error No such name in MIB error Not assignable value for the var error Read only variable, write not allowed err Snmp gen error Access to modify or read not granted err Variable data type wrong error Wrong data length error Wrong encoding error Wrong value for the var type No creationg error Inconsistent value error Resource unavailbe error Modification update failed error Modification undo failed Authorization failed error Variable read only Inconsistent name No such object error No such instance error Reached to end of mib error
346
10.15 SNMP
char Community name array community[NOTIFY_COMMUNITY_LEN]; BYTE communityLen; SNMP_ID agentIDVar; BYTE notificationCode; UDP_SOCKET socket; DWORD_VAL timestamp; SNMP_ID trapIDVar; Section SNMP trap notification information for agent Community name length Agent id for trap identification Trap notification code Udp socket number Time stamp for trap SNMPV2 specific trap
347
10.15 SNMP
348
349
10.15 SNMP
350
351
352
10.15 SNMP C BOOL IsValidInt( DWORD* val ); Description This is function IsValidInt.
353
10.15 SNMP C BYTE IsValidStructure( WORD* dataLen ); Description This is function IsValidStructure.
354
10.15 SNMP
10.15 SNMP C static BOOL ProcessVariables( PDU_INFO* pduDbPtr, char* community, BYTE len ); Description
Once the received pdu is validated as Snmp pdu, it is forwarded for processing to this routine. This rotuine handles Get, Get_Next, Get_Bulk, Set request and creates appropriate response as Get_Response. This routine will decide on whether the request pdu should be processed or be discarded. Remarks None Preconditions The received udp packet is varified as SNMP request. ProcessHeader ( page 354)() returns but FALSE. Parameters Parameters pduDbPtr community len Return Values Return Values TRUE FALSE Description If the snmp request processing is successful. If the processing failed else the processing is not completed. Description Pointer to received pdu information database Pointer to var, storing community string in rxed pdu Pointer to var, storing community string length rxed in pdu see page 355)() and ProcessGetSetHeader ( see
356
10.15 SNMP Remarks None Preconditions SNMPInit ( Return Values Return Values TRUE FALSE see page 357)() is already called.
Functions
Description If SNMP module has finished with a state If a state has not been finished.
10.15.4 Functions
Functions Name getSnmpV2GenTrapOid ( ProcessGetBulkVar ( ProcessGetNextVar ( ProcessGetVar ( Description see page 359) Resolves generic trap code to generic trap OID. This is function ProcessGetBulkVar. This is function ProcessGetNextVar. This is function ProcessGetVar. This is function ProcessSnmpv3MsgData. To search for exact index node in case of a Sequence variable.
SNMPIdRecrdValidation ( SNMPIsValidSetLen (
see page 361) Used to Restrict the access dynamic and non dynamic OID string for A perticular SNMP Version. Validates the set variable data length to data type. This is function Snmpv3AESDecryptRxedScopedPdu. This is function Snmpv3BufferPut. This is function Snmpv3FormulateEngineID. This is function Snmpv3GetAuthEngineTime. This is function Snmpv3GetBufferData. This is function Snmpv3InitializeUserDataBase.
Snmpv3AESDecryptRxedScopedPdu ( see page 362) Snmpv3BufferPut ( see page 362) see page see page Snmpv3FormulateEngineID ( 363) Snmpv3GetAuthEngineTime ( 363) Snmpv3GetBufferData (
Snmpv3MsgProcessingModelProcessPDU This is function Snmpv3MsgProcessingModelProcessPDU. ( see page 364) Snmpv3Notify ( see page 364) see This is function Snmpv3Notify. This is function Snmpv3ScopedPduProcessing. Snmpv3ScopedPduProcessing ( page 364) Snmpv3TrapScopedpdu (
see page 364) This is function Snmpv3TrapScopedpdu. This is function Snmpv3UserSecurityModelProcessPDU. This is function Snmpv3UsmAesEncryptDecryptInitVector.
358
10.15 SNMP
Microchip TCP/IP Stack Help Snmpv3UsmOutMsgAuthenticationParam ( see page 365) Snmpv3ValidateEngineId ( 365) see page
Functions
This is function Snmpv3UsmOutMsgAuthenticationParam. This is function Snmpv3ValidateEngineId. This is function Snmpv3ValidateSecNameAndSecLvl. This is function Snmpv3ValidateSecurityName.
Snmpv3ValidateSecNameAndSecLvl ( see page 366) Snmpv3ValidateSecurityName ( page 366) Module SNMP ( see page 315) see
359
Functions
Functions
This is a callback function called by SNMP module. SNMP user must implement this function in user application and provide appropriate data when called. This function will only be called for OID variable of type sequence. Remarks Only sequence index needs to be handled in this function. Preconditions None Parameters Parameters var index Return Values Return Values TRUE FALSE Description If the exact index value exists for given variable at given index. Otherwise. Description Variable id as per mib.h (input) Index of variable (input)
Functions
362
10.15 SNMP C BOOL Snmpv3BufferPut( BYTE val, SNMPV3MSGDATA * putbuf ); Description This is function Snmpv3BufferPut.
Functions
363
10.15 SNMP C
Functions
364
10.15 SNMP C UINT8 Snmpv3TrapScopedpdu( SNMP_ID var, SNMP_VAL val, SNMP_INDEX index, UINT8 targetIndex ); Description This is function Snmpv3TrapScopedpdu.
Functions
Types
10.15.5 Types
Enumerations Name INOUT_SNMP_PDU ( page 366) Module SNMP ( Structures Name SNMPNONMIBRECDINFO ( see page 367) SNMPV3MSGDATA ( page 367) see Description This is type SNMPNONMIBRECDINFO. SNMPv3 see page 315) see Description This is type INOUT_SNMP_PDU.
366
10.15 SNMP C typedef enum { SNMP_RESPONSE_PDU = 0x01, SNMP_REQUEST_PDU = 0x02 } INOUT_SNMP_PDU; Description This is type INOUT_SNMP_PDU.
Variables
10.15.6 Variables
Module SNMP ( Variables Name getZeroInstance ( see page 368) Description This variable is used for gext next request for zero instance This is variable gSNMPv3ScopedPduDataPos. This is variable gSNMPv3ScopedPduRequestBuf. see page 315)
367
10.15 SNMP
Microchip TCP/IP Stack Help gSNMPv3ScopedPduResponseBuf This is variable gSNMPv3ScopedPduResponseBuf. ( see page 368) msgSecrtyParamLenOffset ( page 369) see This is variable msgSecrtyParamLenOffset.
Variables
368
10.15 SNMP
Macros
10.15.7 Macros
Macros Name Description
IS_SNMPV3_AUTH_STRUCTURE This is macro IS_SNMPV3_AUTH_STRUCTURE. ( see page 369) REPORT_RESPONSE ( page 369) SNMP_MAX_MSG_SIZE ( page 370) see see This is macro REPORT_RESPONSE. SNMP MIN and MAX message 484 bytes in size As per RFC 3411 snmpEngineMaxMessageSize and RFC 1157 ( section 4- protocol specification ) and implementation supports more than 484 whenever feasible. This is macro SNMP_V3.
369
The following functions and variables are available to the stack application.
371
This function requires once available UDP socket while processing, but frees that socket when the SNTP module is idle. Preconditions UDP is initialized.
NTP_FAST_QUERY_INTERVAL Defines how long to wait to retry an update after a failure. Updates may take ( see page 374) up to 6 seconds to fail, so this 14 second delay is actually only an 8-second retry. NTP_QUERY_INTERVAL ( see page 374) NTP_REPLY_TIMEOUT ( page 375) NTP_SERVER ( see Defines how frequently to resynchronize the date/time (default: 10 minutes) Defines how long to wait before assuming the query has failed
see page 375) These are normally available network time servers. The actual IP returned from the pool will vary every minute so as to spread the load around stratum 1 timeservers. For best accuracy and network overhead you should locate the pool server closest to your geography, but it will still work if you use the global pool.ntp.org address or choose the wrong one or ship your embedded device to another geography. see Port for contacting NTP servers
NTP_SERVER_PORT ( page 375) Module SNTP Client ( Structures Name NTP_PACKET ( 372) Variables Name dwLastUpdateTick ( page 373) dwSNTPSeconds ( page 374) Description see see see page 370)
Description Tick count of last update Seconds value obtained by last update
The following functions and variables are designated as internal to the SNTP Client module.
372
10.16 SNTP Client C typedef struct { struct { BYTE mode : 3; BYTE versionNumber : 3; BYTE leapIndicator : 2; } flags; BYTE stratum; CHAR poll; CHAR precision; DWORD root_delay; DWORD root_dispersion; DWORD ref_identifier; DWORD ref_ts_secs; DWORD ref_ts_fraq; DWORD orig_ts_secs; DWORD orig_ts_fraq; DWORD recv_ts_secs; DWORD recv_ts_fraq; DWORD tx_ts_secs; DWORD tx_ts_fraq; } NTP_PACKET; Members Members struct { BYTE mode : 3; BYTE versionNumber : 3; BYTE leapIndicator : 2; } flags; BYTE mode : 3; BYTE versionNumber : 3; BYTE leapIndicator : 2; BYTE stratum; CHAR poll; CHAR precision; DWORD root_delay; DWORD root_dispersion; DWORD ref_identifier; DWORD ref_ts_secs; DWORD ref_ts_fraq; DWORD orig_ts_secs; DWORD orig_ts_fraq; DWORD recv_ts_secs; DWORD recv_ts_fraq; DWORD tx_ts_secs; DWORD tx_ts_fraq; Description Defines the structure of an NTP packet
NTP mode SNTP version number Leap second indicator Stratum level of local clock Poll interval Precision (seconds to nearest power of 2) Root delay between local machine and server Root dispersion (maximum error) Reference clock identifier Reference timestamp (in seconds) Reference timestamp (fractions) Origination timestamp (in seconds) Origination timestamp (fractions) Time at which request arrived at sender (seconds) Time at which request arrived at sender (fractions) Time at which request left sender (seconds) Time at which request left sender (fractions)
373
10.16 SNTP Client C DWORD dwLastUpdateTick = 0; Description Tick count of last update
374
10.17 SSL
10.17 SSL
Files Name SSLClientSize.h ( Description The SSL module adds encryption support to the TCP layer by implementing the SSLv3 protocol. This protocol is the standard for secure communications across the Internet, and prevents snooping or tampering of data as it travels across an untrusted network. This implementation of SSL supports the RSA asymmetric encryption protocol and the ARCFOUR symmetric encryption protocol. see page 438) Description This is file SSLClientSize.h.
375
10.17 SSL
SSL Server Maximum RSA key length (SSL_RSA_KEY_SIZE ( see page 384)) 1024 1024 2048
SSL Client Maximum RSA key length (SSL_RSA_CLIENT_SIZE ( see page 384)) 1024 1024 2048
To comply with US Export Control restrictions, the encryption portion of the SSL module must be purchased separately from Microchip. The library of Data Encryption Routines (SW300052) is available for a nominal fee from http://www.microchipdirect.com/productsearch.aspx?Keywords=SW300052. This TCP/IP Stack version includes modifications to the SSL module to enable an expanded range of RSA key lengths. This will allow the TCP/IP Stack to support a wider range of SSL client/servers. Because of these changes, you must manually modify your copy of RSA.c if you are using version 2.6 of the Data Encryption Routines. The list of required changes ("Required SSL changes.pdf") can be found in the Microchip Applications Libraries installation directory, in the \Microchip\Help\Supplementary TCPIP Help subdirectory. SSL Client Support An SSL client can be initiated by first opening a TCP connection, then calling TCPStartSSLSession to initiate the SSL handshake process. The handshake uses the public key from the certificate provided by the server. Key lengths up to 1024 bits are supported on all processors; key lengths up to 2048 bits are supported on PIC32 microcontrollers. The SSL_RSA_CLIENT_SIZE ( see page 384) macro in SSLClientSize.h ( see page 438) sets the maximum certificate key length that your client should process. #define SSL_RSA_CLIENT_SIZE than key size) (1024ul) // Size of Encryption Buffer (must be larger
Once the handshake has started, call TCPSSLIsHandshaking ( see page 381) until it returns FALSE. This will indicate that the handshake has completed and all traffic is now secured using 128-bit ARCFOUR encryption. If the handshake fails for any reason, the TCP connection will automatically be terminated as required by the SSL protocol specification. For faster performance, the SSL module caches security parameters for the most recently made connections. This allows quick reconnections to the same node without the computational expense of another RSA handshake. By default, the two most recent connections are cached, but this can be modified in TCPIPConfig.h. SSL client support is already enabled for SMTP. When STACK_USE_SSL_CLIENT is defined, the SMTP module automatically adds a field to SMTPClient ( see page 301) called UseSSL. That field controls whether or not the SMTP client module will attempt to make an SSL connection before transmitting any data. Note that TCP sockets using SSL may required an increase in TX/RX buffer size to support SSL. You can adjust the size of your sockets using the TCP/IP Configuration Utility included with the stack. SSL Server Support To initiate an SSL server, first open a TCP socket for listening using TCPOpen ( see page 455). Then call TCPAddSSLListener ( see page 381) to listen ( see page 172) for incoming SSL connections on an alternate port. This allows a single socket to share application-level resources and listen ( see page 172) for connections on two different ports. Connections occurring on the originally opened port will proceed unsecured, while connections on the SSL port will first complete an SSL handshake to secure the data. If you application will not accept ( see page 166) unsecured traffic, simply open a non-secured socket on a free port number, then verify that each incoming connection is secured (not on that port) by calling TCPIsSSL ( see page 382). SSL server support is automatically enabled for HTTP2 when STACK_USE_SSL_SERVER is defined. By default, the HTTP2 module will then listen ( see page 172) for unsecured traffic on port 80 and secured connections on port 443. This SSL server implementation supports key lengths up to 1024 bits on most PIC microcontrollers, and 2048 bits on PIC32 microcontrollers. The SSL_RSA_KEY_SIZE ( see page 384) macro in TCPIPConfig.h sets the server certificate key length. // Bits in SSL RSA key. This parameter is used for SSL sever 376
(512ul)
Note that TCP sockets using SSL may required an increase in TX/RX buffer size to support SSL. You can adjust the size of your sockets using the TCP/IP Configuration Utility included with the stack. Limitations SSL was designed for desktop PCs with faster processors and significantly more resources than are available on an embedded platform. A few compromises must be made in order to use SSL in a less resource-intensive manner. The SSL client module does not perform any validation or verification of certificates. Doing so would require many root certificates to be stored locally for verification, which is not feasible for memory-limited parts. This does not compromise security once the connection has been established, but does not provide complete security against man-in-the-middle attacks. (This sort of attack is uncommon and would be difficult to execute.) Neither the SSL client nor the server can completely verify MACs before processing data. SSL records include a signature to verify that messages were not modified in transit. This Message Authentication ( see page 86) Code, or MAC, is inserted after at least every 16kB of traffic. (It usually is inserted much more frequently than that.) Without 16kB of RAM to buffer packets for each socket, incoming data must be handed to the application layer before the MAC can be completely verified. Invalid MACs will still cause the connection to terminate immediately, but by the time this is detected some bad data may have already reached the application. Since the ARCFOUR cipher in use is a stream cipher, it would be difficult to exploit this in any meaningful way. An attacker would not be able to control what data is actually modified or inserted, as doing so without knowledge of the key would yield garbage. However, it is important to understand that incoming data is not completely verified before being passed to the application.
Description The SSL certificates used by the TCP/IP Stack's SSL module are stored in the CustomSSLCert.c source file. The following series of steps describe how to create the structures in CustomSSLCert.c using an SSL certificate. 1. Download and install the OpenSSL library. There are several third-party sites that offer SSL installers (e.g. http://www.slproweb.com/products/Win32OpenSSL.html). Note that some distributions may not include all commands specified by the OpenSSL documentation. 2. Open a console and change directory to the OpenSSL/bin folder. 3. If you don't have a key and certificate, you can generate them first. The following example console commands will generate a a 512-bit key: 1. Generate the key: openssl genrsa -out 512bits.key 512 2. Generate the Certificate Signing Request (CSR). You will need to add additional information when prompted: openssl req -new -key 512bits.key -out 512bits.csr 3. Generate the X.509 certificate if self-signing (or send the CSR to a Certificate Authority for signing): openssl x509 -req -days 365 -in 512bits.csr -signkey 512bits.key -out 512bits.crt (note that if the -days option is not specified, the default expiration time is 30 days) 4. For additional documentation, refer to http://www.openssl.org/docs/apps/openssl.html. 4. Parse your key file using the command: openssl.exe asn1parse -in "[directory containing your key]\512bits.key" 5. You should see a screen like this:
377
10.17 SSL
6. If you are not using an ENCX24J600 family device, then the last 5 integers displayed here are the SSL_P, SSL_Q, SSL_dP, SSL_dQ, and SSL_qInv parameters, respectively. However, they are displayed here in big-endian format, and the Microchip cryptographic library implementation requires parameters in little-endian format, so you will have to enter the parameters into the C arrays in opposite order. For example, the INTEGER at offset 145: 145:d=1 h1=2 ;= 33 prim: INTEGER :D777566780029FCD610200B66D89507D 915E3E5BDB6FAB0233B5DFA2E4081DF7 will be swapped in the CustomSSLCert.c file: ROM BYTE SSL_P[] = { 0xF7, 0x1D, 0x08, 0xE4, 0xA2, 0xDF, 0xB5, 0x33, 0x02, 0xAB, 0x6F, 0xDB, 0x5B, 0x3E, 0x5E, 0x91, 0x7D, 0x50, 0x89, 0x6D, 0xB6, 0x00, 0x02, 0x61, 0xCD, 0x9F, 0x02, 0x80, 0x67, 0x56, 0x77, 0xD7 }; 7. If you are using an ENCX24J600 family device, then the second and fourth integers displayed here are the SSL_N and SSL_D parameters, respectively. There is no need to do an endian format change for these parameters. For the example, the expected SSL_N and SSL_D values are shown in the figure below:
8. Parse your X.509 certificate using the command: openssl.exe asn1parse -in "[directory containing your cert]\512bits.crt" -out cert.bin 9. Open the cert.bin output file in a hex editor. For example, here is the default certificate information generated from 512bits.crt given in the stack:
378
10.17 SSL
10. This information must be copied verbatim into the SSL_CERT ( see page 408)[] array. Note that this is binary data (not a large integer) so it does not get endian-swapped like the private key parameters. ROM BYTE SSL_CERT[524] = { 0x30, 0x82, 0x02, 0x08, 0x30, 0x82, 0x01, 0xb2, 0x02, 0x09, 0x00, 0xa5, 0x6a, 0xea, 0x1a, 0xa9, 0x52, 0x9d, 0x1e, 0x30, 0x0d, 0x06, 0x09, 0x2a, 0x86, 0x48, 0x86, 0xf7, 0x0d, 0x01, 0x01, 0x05, 0x05, 0x00, 0x30, 0x81, 0x8a, 0x31, 0x0b, 0x30, 0x09, 0x06, 0x03, 0x55, 0x04, 0x06, 0x13, 0x02, 0x55, 0x53, 0x31, 0x10, 0x30, 0x0e, 0x06, 0x03, 0x55, 0x04, 0x08, 0x13, 0x07, 0x41, 0x72, 0x69, 0x7a, 0x6f, 0x6e, 0x61, 0x31, 0x11, 0x30, 0x0f, 0x06, 0x03, 0x55, 0x04, 0x07, 0x13, 0x08, 0x43, 0x68, 0x61, 0x6e, 0x64, 0x6c, 0x65, 0x72, 0x31, 0x23, 0x30, 0x21, 0x06, 0x03, 0x55, 0x04, 0x0a, 0x13, 0x1a, 0x4d, 0x69, 0x63, 0x72, 0x6f, 0x63, 0x68, 0x69, 0x70, 0x20, 0x54, 0x65, 0x63, 0x68, 0x6e, 0x6f, 0x6c, 0x6f, 0x67, 0x79, 0x2c, 0x20, 0x49, 0x6e, 0x63, 0x2e, 0x31, 0x1d, 0x30, 0x1b, 0x06, 0x03, 0x55, 0x04, 0x0b, 0x13, 0x14, 0x53, 0x53, 0x4c, 0x20, 0x44, 0x65, 0x6d, 0x6f, 0x20, 0x43, 0x65, 0x72, 0x74, 0x69, 0x66, 0x69, 0x63, 0x61, 0x74, 0x65, 0x31, 0x12, 0x30, 0x10, 0x06, 0x03, 0x55, 0x04, 0x03, 0x13, 0x09, 0x6d, 0x63, 0x68, 0x70, 0x62, 0x6f, 0x61, 0x72, 0x64, 0x30, 0x1e, 0x17, 0x0d, 0x30, 0x37, 0x31, 0x30, 0x30, 0x39, 0x31, 0x38, 0x33, 0x37, 0x32, 0x37, 0x5a, 0x17, 0x0d, 0x31, 0x37, 0x31, 0x30, 0x30, 0x36, 0x31, 0x38, 0x33, 0x37, 0x32, 0x37, 0x5a, 0x30, 0x81, 0x8a, 0x31, 0x0b, 0x30, 0x09, 0x06, 0x03, 0x55, 0x04, 0x06, 0x13, 0x02, 0x55, 0x53, 0x31, 0x10, 0x30, 0x0e, 0x06, 0x03, 0x55, 0x04, 0x08, 0x13, 0x07, 0x41, 0x72, 0x69, 0x7a, 0x6f, 0x6e, 0x61, 0x31, 0x11, 0x30, 0x0f, 0x06, 0x03, 0x55, 0x04, 0x07, 0x13, 0x08, 0x43, 0x68, 0x61, 0x6e, 0x64, 0x6c, 0x65, 0x72, 0x31, 0x23, 0x30, 0x21, 0x06, 0x03, 0x55, 0x04, 0x0a, 0x13, 0x1a, 0x4d, 0x69, 0x63, 0x72, 0x6f, 0x63, 0x68, 0x69, 0x70, 0x20, 0x54, 0x65, 0x63, 0x68, 0x6e, 0x6f, 0x6c, 0x6f, 0x67, 0x79, 0x2c, 0x20, 0x49, 0x6e, 0x63, 0x2e, 0x31, 0x1d, 0x30, 0x1b, 0x06, 0x03, 0x55, 0x04, 0x0b, 0x13, 0x14, 0x53, 0x53, 0x4c, 0x20, 0x44, 0x65, 0x6d, 0x6f, 0x20, 0x43, 0x65, 0x72, 0x74, 0x69, 0x66, 0x69, 0x63, 0x61, 0x74, 0x65, 0x31, 0x12, 0x30, 0x10, 0x06, 0x03, 0x55, 0x04, 0x03, 0x13, 0x09, 0x6d, 0x63, 0x68, 0x70, 0x62, 0x6f, 0x61, 0x72, 0x64, 0x30, 0x5c, 0x30, 0x0d, 0x06, 0x09, 0x2a, 0x86, 0x48, 0x86, 0xf7, 0x0d, 0x01, 0x01, 0x01, 0x05, 0x00, 0x03, 0x4b, 0x00, 0x30, 0x48, 0x02, 0x41, 0x00, 0xaa, 0x96, 0xca, 0x97, 0xea, 0x27, 0xb0, 0xd7, 0xe9, 0x21, 0xd0, 0x40, 0xd4, 0x2c, 0x09, 0x5a, 0x2e, 0x3a, 0xe4, 0x12, 0x64, 0x2d, 0x4b, 0x1b, 0x92, 0xdf, 0x79, 0x68, 0x4e, 0x3c, 0x51, 0xf4, 0x43, 0x48, 0x0d, 0xf2, 0xc8, 0x50, 0x9b, 0x6e, 0xe5, 0xea, 0xfe, 0xef, 0xd9, 0x10, 0x41, 0x08, 0x14, 0xf9, 0x85, 0x49, 0xfc, 0x50, 0xd3, 0x57, 0x34, 0xdc, 0x3a, 0x0d, 0x79, 0xf8, 0xd3, 0x99, 0x02, 0x03, 0x01, 0x00, 0x01, 0x30, 0x0d, 0x06, 0x09, 0x2a, 0x86, 0x48, 0x86, 0xf7, 0x0d, 0x01, 0x01, 0x05, 0x05, 0x00, 0x03, 0x41, 0x00, 0x18, 0x18, 0xfe, 0x8b, 0x2d, 0x0d, 0xf7, 0x0d, 0x65, 0x9d, 0x29, 0xec, 0xb3, 0x51, 0x6e, 0x3b, 0x93, 0xbb, 0x40, 0x1a, 0x0b, 0x34, 0x07, 0x63, 0x5e, 0x6a, 0x1c, 0x74, 0x59, 0xd4, 0x54, 0xd2, 0x1b, 0xf3, 0x31, 0xb7, 0x57, 0x4b, 0xa5, 0xe6, 0xe2, 0x35, 0xf7, 0xb3, 0x6a, 0x15, 0x6e, 0x3c, 0x93, 0x85, 0xb2, 0xca, 0xf5, 0x35, 0x00, 0xf4, 0x49, 0xe7, 0x00, 0x8a, 0x00, 0xd8, 0xe8, 0xcf 379
SSL_SUPPLEMENTARY_DATA_TYPES This is type SSL_SUPPLEMENTARY_DATA_TYPES. ( see page 383) Functions Name TCPAddSSLListener ( page 381) see Description Listens for SSL connection on a specific port. Determines if an SSL session is still handshaking. Begins an SSL client session. Determines if a TCP connection is secured with SSL. Begins a new SSL session for the given TCP connection.
TCPSSLIsHandshaking ( see page 381) TCPStartSSLClient ( page 382) TCPIsSSL ( SSLStartSession ( page 383) Macros Name SSL_INVALID_ID ( page 380) see see
Description Identifier for invalid SSL allocations see Bits in SSL RSA key. This parameter is used for SSL sever connections only. The only valid value is 512 bits (768 and 1024 bits do not work at this time). Note, however, that SSL client operations do currently work up to 1024 bit RSA key length. Size of Encryption Buffer (must be larger than key size)
Structures Name SSL_PKEY_INFO ( page 383) Description The following functions and variables are available to the stack application. see Description To hash the public key information, we need to actually get the public key information... 1024 bit key at 8 bits/byte = 128 bytes needed for the public key.
380
381
383
10.17 SSL C
typedef struct { WORD pub_size_bytes; BYTE pub_key[SSL_RSA_CLIENT_SIZE/8]; BYTE pub_e[3]; BYTE pub_guid; } SSL_PKEY_INFO; Members Members BYTE pub_guid; Description To hash the public key information, we need to actually get the public key information... 1024 bit key at 8 bits/byte = 128 bytes needed for the public key. Description This is used as a TCP_SOCKET ( see page 466) which is a BYTE
384
Microchip TCP/IP Stack Help Performs any periodic tasks for the SSL module. Requests an SSL message to be transmitted.
TCPRequestSSLMessage ( see page 386) TCPSSLGetPendingTxSize ( see page 387) TCPSSLHandleIncoming ( see page 387)
Determines how many bytes are pending for a future SSL record. Hands newly arrive TCP data to the SSL module for processing.
TCPSSLHandshakeComplete Clears the SSL handshake flag. ( see page 388) TCPSSLInPlaceMACEncrypt ( see page 388) TCPSSLPutRecordHeader ( see page 389) TCPStartSSLServer ( page 390) Macros Name SSL_MIN_SESSION_LIFETIME ( see page 390) Description Minimum lifetime for SSL Sessions Sessions cannot be reallocated until this much time has elapsed see Encrypts and MACs data in place in the TCP TX buffer. Writes an SSL record header and sends an SSL record. Begins an SSL server session.
SSL_RSA_LIFETIME_EXTENSION Lifetime extension for RSA operations Sessions lifetime is extended by ( see page 390) this amount when an RSA calculation is made Module SSL ( see page 375)
Description The following functions and variables are public, but are intended only to be accessed by the stack itself. Applications should generally not call these functions or modify these variables.
385
10.17 SSL
386
This function is called to request that a specific SSL message be transmitted. This message should only be called by the SSL module. Preconditions TCP is initialized. Parameters Parameters hTCP msg Return Values Return Values TRUE FALSE Description The message was requested. Another message is already pending transmission. Description TCP connection to use One of the SSL_MESSAGE types to transmit.
This function processes incoming TCP data as an SSL record and performs any necessary repositioning and decrypting. Remarks This function should never be called by an application. It is used only by the SSL module itself. Preconditions TCP is initialized, and hTCP is connected with an active SSL session. Parameters Parameters hTCP Description TCP connection to handle incoming data on
388
This function encrypts data in the TCP buffer while calcuating a MAC. When encryption is finished, the MAC is appended to the buffer and the record will be ready to transmit. Remarks This function should never be called by an application. It is used only by the SSL module itself. Preconditions TCP is initialized, hTCP is connected, and ctx's Sbox is loaded. Parameters Parameters hTCP ctx MACSecret len Description TCP connection to encrypt in ARCFOUR encryption context to use MAC encryption secret to use Number of bytes to crypt
389
10.17 SSL
390
10.17 SSL
SM_SSL_RX_SERVER_HELLO State machine for SSLRxServerHello ( ( see page 404) SSL_ALERT_LEVEL ( page 405) SSL_MESSAGES ( 410) see Describes the two types of Alert records
Describes the types of SSL messages (handshake and alerts) SSL Session Type Enumeration
SSL_SESSION_TYPE ( page 413) Functions Name CalculateFinishedHash ( see page 396) GenerateHashRounds ( see page 396) GenerateSessionKeys ( see page 397) HSEnd ( HSGet ( see page 397) see page 398)
Description Calculates the handshake hash over the data. hashID can be either MD5 or SHA-1, and this function will calculate accordingly. Generates hash rounds to find either the Master Secret or the Key Block. Generates the session write keys and MAC secrets Hashes ( see page 199) the message contents into the Handshake hash structures and begins a new handshake hash. Reads data from socket, transparently hashing it into the handshake hashes. Function: static WORD HSGetArray(TCP_SOCKET ( BYTE *data, WORD len) * PreCondition: None * Input: skt - socket to read data from data - array to read into, or NULL len - number of bytes to read * Output: Number of bytes read * Side Effects: None * Overview: Reads data from socket, transparently hashing it into the handshake hashes. * Note: None see page 466) skt,
HSGetArray (
HSGetWord ( HSPut (
see page 399) Reads data from socket, transparently hashing it into the handshake hashes. Writes data to socket, transparently hashing it into the handshake hashes.
391
Function: static WORD HSPutArray(TCP_SOCKET ( BYTE *data, BYTE len) * PreCondition: None * Input: skt - socket to write data to data - data to write len - number of bytes to write * Output: Number of bytes written * Side Effects: None *
Overview: Writes data to socket, transparently hashing it into the handshake hashes. * Note: None HSPutROMArray ( page 401) HSPutWord ( HSStart ( LoadOffChip ( 403) SaveOffChip ( 404) see This is function HSPutROMArray.
see page 401) Writes data to socket, transparently hashing it into the handshake hashes. Sets up the buffer to store data for handshake hash tracking Copies data from Ethernet RAM to local RAM Copies data in PIC RAM to the Ethernet RAM Allocates a buffer for use. Specified buffer is released Specified buffer is loaded to RAM. Only loads if necessary, and saves any current buffer before switching. Allocates a hash for use. Specified hash is released Specified hash is loaded to RAM. Only loads if necessary, and saves any current hash before switching. Specified key set is loaded to RAM. Only loads if necessary, and saves any current key set before switching. This is function SSLMACAdd. This is function SSLMACBegin. This is function SSLMACCalc. Pauses connection processing until RSA calculation is complete. see page see page see page see page see page see page see page see page see page see page see page see page see
SSLBufferAlloc ( 415) SSLBufferFree ( 416) SSLBufferSync ( 417) SSLHashAlloc ( 418) SSLHashFree ( 418) SSLHashSync ( 419) SSLKeysSync ( 420) SSLMACAdd ( 421) SSLMACBegin ( 421) SSLMACCalc ( 421)
392
10.17 SSL SSLRxAntiqueClientHello ( see page 423) SSLRxCCS ( SSLRxClientHello ( page 424) see
Receives the SSLv2 ClientHello message, initiating a new SSL session with a client Receives the ClientHello message, initiating a new SSL session with a client Receives the ClientKeyExchange message and begins the decryption process. Receives the Finished message from remote node Receives a handshake message. Receives an SSL record. Receives ServerCertificate from the remote server, locates the public key information, and executes RSA operation. Receives the ServerHello from the remote server Locates a cached SSL session for reuse. Syncs found session into RAM. Locates a cached SSL session for reuse Finds space for a new SSL session Specified session is loaded to RAM. Only loads if necessary, and saves any current session before switching if it has been updated. Begins a long SSL record. Allocates a stub for use. Specified stub is released Specified stub is loaded to RAM. Only loads if necessary, and saves any current stub before switching. Terminates an SSL connection and releases allocated resources. Generates the session keys from the master secret, then allocates and generates the encryption context. Once processing is complete, transmits the Change Cipher Spec message and the Finished handshake message to the server. Transmits the ClientHello message to initiate a new SSL session with the server. Transmits the encrypted pre-master secret to the server and requests the Change Cipher Spec. Also generates the Master Secret from the pre-master secret that was used. Transmits an SSL message. Transmits an SSL record. Transmits the Certificate message with the server's specified public key certificate. Transmits the ServerHello message. Transmits the ServerHelloDone message.
see page
SSLRxServerCertificate ( see page 426) SSLRxServerHello ( page 427) SSLSessionMatchID ( page 428) SSLSessionMatchIP ( page 428) SSLSessionNew ( page 429) SSLSessionSync ( page 430) see see see see see
SSLStartPartialRecord ( see page 431) SSLStubAlloc ( 432) SSLStubFree ( 432) SSLStubSync ( 433) SSLTerminate ( 433) SSLTxCCSFin ( 434) see page see page see page see page see page
see
SSLTxClientKeyExchange ( see page 435) SSLTxMessage ( 435) SSLTxRecord ( 436) see page see page
393
Description see page 403) Total space needed by all SSL storage requirements Protocol code for Alert records Protocol code for Application data records Base address for SSL buffers Base address for SSL hashes Base address for SSL keys Base address for SSL sessions Base address for SSL stubs Amount of space needed by a single SSL buffer Amount of space needed by all SSL buffer
SSL_APPLICATION (
SSL_BUFFER_SPACE (
see page 408) Protocol code for Change Cipher Spec records Protocol code for Handshake records Amount of space needed by a single SSL hash Amount of space needed by all SSL hash Amount of space needed by a single SSL key Amount of space needed by all SSL key
SSL_HASH_SPACE ( SSL_KEYS_SIZE (
SSL_KEYS_SPACE (
SSL_RSA_EXPORT_WITH_ARCFOUR_40_MD5 This is macro ( see page 411) SSL_RSA_EXPORT_WITH_ARCFOUR_40_MD5. SSL_RSA_WITH_ARCFOUR_128_MD5 ( page 411) SSL_SESSION_SIZE ( SSL_STUB_SIZE ( SSL_VERSION ( see page 412) see page 412) SSL_SESSION_SPACE ( SSL_STUB_SPACE ( SSL_VERSION_HI ( SSL_VERSION_LO ( see This is macro SSL_RSA_WITH_ARCFOUR_128_MD5. Amount of space needed by a single SSL session Amount of space needed by all SSL session Amount of space needed by a single SSL stub Amount of space needed by all SSL stubs SSL version number SSL version number (high byte) SSL version number (low byte) This is macro SSLFinishPartialRecord. This is macro SSLFlushPartialRecord. This is macro SSLSessionUpdated.
see page 414) see page 414) see page 415) see page 415) see page 417) see page 417) see page 415)
394
Description see page 409) Memory definition for SSL keys. This area is split into Local and Remote areas. During the handshake, Local.random and Remote.random hold the ServerRandom and ClientRandom values. Once the session keys are calculated, the Local.app and Remote.app contain the MAC secret, record sequence number, and encryption context for the ARCFOUR module. see page Storage space for SSL Session identifiers. (The SessionID and MasterSecret) Stub value for an SSL_SESSION ( see page 411). The tag associates this session with a remote node, either by matching to a remote IP address when we are the client or the first 3 bytes of the session ID when we are the host. When a session is free/expired, the tag is 0x00000000. The lastUsed value is the Tick count when the session was last used so that older sessions may be overwritten first.
SSL_SESSION ( 411)
see page 413) Memory holder for general information associated with an SSL connections.
Description see page Generic buffer space for SSL. The hashRounds element is used when this buffer is needed for handshake hash calculations, and the full element is used as the Sbox for ARCFOUR calculations.
SSL_BUFFER ( 407) Variables Name isBufferUsed ( 402) isHashUsed ( isStubUsed ( masks ( ptrHS (
see page 402) Indicates which hashes are in use see page 402) Indicates which stubs are in use Masks for each bit in the is*Used variables Used in buffering handshake results RSA public certificate length ?
SSL_CERT (
see page 416) Which buffer is loaded Hash storage Which hash is loaded The current SSL session Which SSL_KEYS ( see page 409) are loaded Which stub is using RSA, if any Current session data Which session is loaded see page 419) see page 420) see page
sslSessionStubs ( 429)
see page 8 byte session stubs see Whether or not it has been updated The current SSL stub Which SSL_STUB ( see page 413) is loaded
The following functions and variables are designated as internal to the SSL module.
395
10.17 SSL
396
This function will overflow the buffer after 7 rounds, but in practice num = 3 or num = 4. Preconditions The SSL buffer is allocated for temporary usage and the data to run rounds on is in sslSession.masterSecret Parameters Parameters num rand1 rand2 Description how many rounds to compute the first random data block to use the second random data block to use
397
10.17 SSL Input: skt - socket to read data from data - array to read into, or NULL len - number of bytes to read * Output: Number of bytes read * Side Effects: None *
Overview: Reads data from socket, transparently hashing it into the handshake hashes. * Note: None
10.17 SSL TCP_SOCKET skt, BYTE b ); Side Effects None Returns Number of bytes written Description
Writes data to socket, transparently hashing it into the handshake hashes. Remarks None Preconditions None Parameters Parameters skt b Description socket to write data to byte to write
Sets up the buffer to store data for handshake hash tracking Remarks None Preconditions None Section Handshake Hash and I/O Functions
402
10.17 SSL
403
10.17 SSL Description Copies data from Ethernet RAM to local RAM Remarks None Preconditions None Parameters Parameters ramAddr ethAddr len
Description destination address in RAM source address in Ethernet RAM number of bytes to copy
404
10.17 SSL C typedef enum { RX_SERVER_CERT_START = 0u, RX_SERVER_CERT_FIND_KEY, RX_SERVER_CERT_FIND_N, RX_SERVER_CERT_READ_N, RX_SERVER_CERT_READ_E, RX_SERVER_CERT_CLEAR } SM_SSL_RX_SERVER_HELLO; Description State machine for SSLRxServerHello (
405
10.17 SSL
406
10.17 SSL C
407
10.17 SSL
408
10.17 SSL C
#define SSL_HASH_SIZE ((DWORD)sizeof(HASH_SUM)) a single SSL hash Description Amount of space needed by a single SSL hash
Memory definition for SSL keys. This area is split into Local and Remote areas. During the handshake, Local.random and Remote.random hold the ServerRandom and ClientRandom values. Once the session keys are calculated, the Local.app and Remote.app contain the MAC secret, record sequence number, and encryption context for the ARCFOUR module.
10.17 SSL SSL_CLIENT_HELLO = 1u SSL_ANTIQUE_CLIENT_HELLO = 18u SSL_SERVER_HELLO = 2u SSL_CERTIFICATE = 11u SSL_SERVER_HELLO_DONE = 14u SSL_CLIENT_KEY_EXCHANGE = 16u SSL_FINISHED = 20u
SSLv2 ClientHello handshake message (Supported for backwards compatibility. This is an internally defined value.) ServerHello handshake message ServerCertifiate handshake message ServerHelloDone handshake message ClientKeyExchange handshake message Finished handshake message
SSL_ALERT_CLOSE_NOTIFY = 0u+0x80 CloseNotify alert message (dummy value used internally) SSL_ALERT_UNEXPECTED_MESSAGE UnexpectedMessage alert message (dummy value used internally) = 10u+0x80 SSL_ALERT_BAD_RECORD_MAC = 20u+0x80 SSL_ALERT_HANDSHAKE_FAILURE = 40u+0x80 SSL_NO_MESSAGE = 0xff Description Describes the types of SSL messages (handshake and alerts) BadRecordMAC alert message (dummy value used internally) HandshakeFailure alert message (dummy value used internally) No message is currently requested (internally used value)
Description The SSL Session ID for this session Associated Master Secret for this session
Storage space for SSL Session identifiers. (The SessionID and MasterSecret)
Stub value for an SSL_SESSION ( see page 411). The tag associates this session with a remote node, either by matching to a remote IP address when we are the client or the first 3 bytes of the session ID when we are the host. When a session is 412
10.17 SSL
free/expired, the tag is 0x00000000. The lastUsed value is the Tick count when the session was last used so that older sessions may be overwritten first.
413
10.17 SSL Members Members WORD wRxBytesRem; WORD wRxHsBytesRem; BYTE rxProtocol; BYTE rxHSType; BYTE idSession; BYTE idRxHash; DWORD_VAL dwTemp; unsigned char bIsServer : 1; unsigned char bClientHello : 1; unsigned char bServerHello : 1; unsigned char bServerCertificate : 1; unsigned char bServerHelloDone : 1; unsigned char bClientKeyExchange : 1; unsigned char bRemoteChangeCipherSpec : 1; unsigned char bRemoteFinished : 1; unsigned char bLocalChangeCipherSpec : 1; unsigned char bLocalFinished : 1; unsigned char bExpectingMAC : 1; unsigned char bNewSession : 1; unsigned char bCloseNotify : 1; unsigned char bDone : 1; unsigned char bRSAInProgress : 1; unsigned char bKeysValid : 1; BYTE requestedMessage; Description
Description Bytes left to read in current record Bytes left to read in current Handshake submessage Protocol for message being read Handshake message being received ID for associated session ID for MAC hash (TX needs no persistence) Used for state machine in RxCertificate We are the server ClientHello has been sent/received ServerHello has been sent/received ServerCertificate has been sent/received ServerHelloDone has been sent/received ClientKeyExchange has been sent/received Remote node has sent a ChangeCipherSpec message Remote node has sent a Finished message We have sent a ChangeCipherSpec message We have sent a Finished message We expect a MAC at end of message TRUE if a new session, FALSE if resuming Whether or not a CloseNotify has been sent/received TRUE if the connection is closed TRUE when RSA op is in progress TRUE if the session keys have been generated Currently requested message to send, or 0xff
414
10.17 SSL C
#define SSL_STUB_SPACE (SSL_STUB_SIZE*MAX_SSL_CONNECTIONS) by all SSL stubs Description Amount of space needed by all SSL stubs
10.17 SSL Returns id - Allocated buffer ID, or SSL_INVALID_ID ( Description Allocates a buffer for use. Remarks None Preconditions None Parameters Parameters id
416
10.17 SSL
417
10.17 SSL
418
419
10.17 SSL
420
10.17 SSL
Pauses connection processing until RSA calculation is complete. Remarks This function exists outside of the handshaking functions so that the system does not incur the expense of resuming and suspending handshake hashes. Preconditions The RSA Module has been secured, an RSA operation is pending, sslStub.wRxHsBytesRem is the value of sslStub.wRxBytesRem after completion, and sslStub.wRxBytesRem is the value of sslStub.rxProtocol after completion. Also requires sslStub ( see page 431) to be synchronized. Section Function Prototypes
10.17 SSL Preconditions sslStub ( Parameters Parameters hTCP see page 431) is synchronized
10.17 SSL Remarks None Preconditions sslStub ( Parameters Parameters hTCP see page 431) is synchronized.
424
Receives the ClientKeyExchange message and begins the decryption process. Remarks None Preconditions sslStub ( Parameters Parameters hTCP Description the TCP Socket to read from see page 431) is synchronized and HSStart ( see page 401)() has been called.
425
This function receives handshake messages, reads the handshake header, and passes the data off to the appropriate handshake parser. Preconditions The specified SSL stub is initialized and the TCP socket is connected. Also requires that rxBytesRem has been populated and the current SSL stub has been synced into memory. Parameters Parameters hTCP Description The TCP socket to read a handshake message from
426
Receives ServerCertificate from the remote server, locates the public key information, and executes RSA operation. Remarks This shortcuts full parsing of the certificate by just finding the Public Key Algorithm identifier for RSA. From there, the following ASN.1 struct is the public key. That struct consists of the value for N, followed by the value for E. Preconditions sslStub ( Parameters Parameters hTCP Description the TCP Socket to read from see page 431) is synchronized and HSStart ( see page 401)() has been called.
427
10.17 SSL C static BYTE SSLSessionMatchIP( IP_ADDR ip ); Side Effects None Returns
The matched session ID, or SSL_INVALID_ID ( Description Locates a cached SSL session for reuse Remarks None Preconditions None Parameters Parameters ip Section Client messages
429
10.17 SSL C
430
10.17 SSL C BOOL sslSessionUpdated; Description Whether or not it has been updated
431
10.17 SSL
Terminates an SSL connection and releases allocated resources. Preconditions None Parameters Parameters id Description the SSL stub ID to terminate
Transmits the ClientHello message to initiate a new SSL session with the server. Remarks None Preconditions Enough space is available in hTCP to write the entire message. Parameters Parameters hTCP Description the TCP Socket to send the message to
435
10.17 SSL C void SSLTxMessage( TCP_SOCKET hTCP, BYTE sslStubID, BYTE msg ); Returns None Description
This function transmits a specific SSL message for handshakes and alert messages. Supported messages are listed in SSL_MESSAGES ( see page 410). Preconditions The specified SSL stub is initialized and the TCP socket is connected. Parameters Parameters hTCP id msg Description The TCP socket with data waiting to be transmitted The active SSL stub ID One of the SSL_MESSAGES ( see page 410) types to send
10.17 SSL C
static void SSLTxServerCertificate( TCP_SOCKET hTCP ); Side Effects None Returns None Description Transmits the Certificate message with the server's specified public key certificate. Remarks Certificate is defined in CustomSSLCert.c. This function requires special handling for partial records because the certificate will likely be larger than the TCP buffer, and SSL handshake messages are constrained to fit in a single SSL handshake record Preconditions None Parameters Parameters hTCP Description the TCP Socket to send the message to
437
10.18 TCP
10.17.5 Files
Files Name SSLClientSize.h ( Module SSL ( see page 375) see page 438) Description This is file SSLClientSize.h.
10.17.5.1 SSLClientSize.h
Macros Name SSL_RSA_CLIENT_SIZE ( see page 384) Description This is file SSLClientSize.h. Description Size of Encryption Buffer (must be larger than key size)
438
10.18 TCP
10.18 TCP
Variables Name NextPort ( Description TCP is a standard transport layer protocol described in RFC 793. It provides reliable stream-based connections over unreliable networks, and forms the foundation for HTTP, SMTP, and many other protocol standards. Connections made over TCP guarantee data transfer at the expense of throughput. Connections are made through a three-way handshake process, ensuring a one-to-one connection. Remote nodes advertise how much data they are ready to receive, and all data transmitted must be acknowledged. If a remote node fails to acknowledge the receipt of data, it is automatically retransmitted. This ensures that network errors such as lost, corrupted, or out-of-order packets are automatically corrected. To accomplish this, TCP must operate in a buffer. Once the transmit buffer is full, no more data can be sent until the remote node has acknowledged receipt. For the Microchip TCP/IP Stack, the application must return to the main stack loop in order for this to happen. Likewise, the remote node cannot transmit more data until the local device has acknowledged receipt and that space is available in the buffer. When a local application needs to read more data, it must return to the main stack loop and wait for a new packet to arrive. The TCP flow diagram below provides an overview for the use of the TCP module: see page 484) Description Tracking variable for next local client port number
Sockets ( see page 149) are opened using TCPOpen ( see page 455). This function can either open a listening socket to wait for client connections, or can make a client connection to the remote node. The remote node can be specified by a host name string to be resolved in DNS, an IP address, or a NODE_INFO struct containing previously resolved IP and MAC address information. Once connected, applications can read and write data. On each entry, the application must verify that the socket is still connected. For most applications a call to TCPIsConnected ( see page 453) will be sufficient, but TCPWasReset ( see page 462) may also be used for listening sockets that may turn over quickly. To write data, call TCPIsPutReady ( see page 454) to check how much space is available. Then, call any of the TCPPut ( see page 458) family of functions to write data as space is available. Once complete, call TCPFlush ( see page 450) to transmit data immediately. Alternately, return to the main stack loop. Data will be transmitted when either a) half of the transmit buffer becomes full or b) a delay time has passed (usually 40ms). To read data, call TCPIsGetReady ( see page 454) to determine how many bytes are ready to be retrieved. Then use the TCPGet ( see page 450) family of functions to read data from the socket, and/or the TCPFind ( see page 447) family of functions to locate data in the buffer. When no more data remains, return to the main stack loop to wait for more data to 439
If the application needs to close the connection, call TCPDisconnect ( see page 446), then return to the main stack loop and wait for the remote node to acknowledge the disconnection. Client sockets will return to the idle state, while listening sockets will wait for a new connection. For more information, refer to the GenericTCPClient ( read the associated RFC. see page 95) or GenericTCPServer ( see page 98) examples, or
see page 446) Discards any pending data in the TCP RX FIFO. see page see
see page 448) Searches for a byte in the TCP RX buffer. see Searches for a ROM string in the TCP RX buffer. Immediately transmits all pending TX data. Retrieves a single byte to a TCP socket. Reads an array of data bytes from a TCP socket's receive FIFO. The data is removed from the FIFO in the process. Obtains information about a currently open socket. Determines how many bytes are free in the RX FIFO. Determines how many bytes are pending in the TCP TX FIFO. Determines if a socket has an established connection.
see page 450) see page 450) see page see see see see
TCPGetArray ( 451)
TCPGetRemoteInfo ( page 451) TCPGetRxFIFOFree ( page 452) TCPGetTxFIFOFull ( page 453) TCPIsConnected ( page 453) TCPIsGetReady ( 454) TCPIsPutReady ( 454) TCPOpen ( TCPPeek (
see page Determines how many bytes can be read from the TCP RX buffer. see page Determines how much free space is available in the TCP TX buffer. Opens a TCP socket for listening or as a client. Peaks at one byte in the TCP RX FIFO without removing it from the buffer. Reads a specified number of data bytes from the TCP RX FIFO without removing them from the buffer. Writes a single byte to a TCP socket. Writes an array from RAM to a TCP socket. Writes an array from ROM to a TCP socket. Writes a null-terminated string from ROM to a TCP socket. The null-terminator is not copied to the socket.
440
10.18 TCP TCPPutString ( 460) TCPRAMCopy ( 460) see page see page see
Writes a null-terminated string from RAM to a TCP socket. The null-terminator is not copied to the socket. Copies data to/from various memory mediums. Copies data to/from various memory mediums. Self-clearing semaphore inidicating socket reset.
see page
Description see page 442) The socket is invalid or could not be opened see page The socket is not known
UNKNOWN_SOCKET ( 442)
TCP_ADJUST_GIVE_REST_TO_RX Resize flag: extra bytes go to RX ( see page 442) TCP_ADJUST_GIVE_REST_TO_TX Resize flag: extra bytes go to TX ( see page 442) TCP_ADJUST_PRESERVE_RX ( see page 442) TCP_ADJUST_PRESERVE_TX ( see page 443) TCP_OPEN_IP_ADDRESS ( page 443) TCP_OPEN_NODE_INFO ( page 443) TCP_OPEN_RAM_HOST ( page 443) TCP_OPEN_ROM_HOST ( page 444) TCP_OPEN_SERVER ( 444) TCPConnect ( TCPFind ( TCPFindArray ( see Resize flag: attempt to preserve RX buffer Resize flag: attempt to preserve TX buffer Emit an undeclared identifier diagnostic if code tries to use TCP_OPEN_IP_ADDRESS while STACK_CLIENT_MODE feature is not enabled. Emit an undeclared identifier diagnostic if code tries to use TCP_OPEN_NODE_INFO while STACK_CLIENT_MODE feature is not enabled. Emit an undeclared identifier diagnostic if code tries to use TCP_OPEN_RAM_HOST while STACK_CLIENT_MODE feature is not enabled. Emit an undeclared identifier diagnostic if code tries to use TCP_OPEN_ROM_HOST while STACK_CLIENT_MODE feature is not enabled. Create a server socket and ignore dwRemoteHost. Alias to TCPOpen ( Alias to TCPFindEx ( see page 455) as a client. see page 448) with no length parameter. see page 447) with no length parameter. see page 449) with no length
see
see
see
see page
Alias to TCPFindArrayEx (
TCPFindROMArray ( TCPGetRxFIFOFull ( TCPGetTxFIFOFree ( 453) TCPListen ( Module TCP ( see page 439)
see page 449) Alias to TCPFindROMArrayEx ( parameter. see page 452) Alias to TCPIsGetReady ( completeness see page Alias to TCPIsPutReady ( completeness Alias to TCPOpen (
see page 454) provided for API see page 454) provided for API
Description The following functions and variables are available to the stack application.
441
10.18 TCP
442
10.18 TCP C
10.18 TCP
444
10.18 TCP Preconditions TCP is initialized. Parameters Parameters hTCP wMinRXSize wMinTXSize vFlags
Description The socket to be adjusted Minimum number of byte for the RX FIFO Minimum number of bytes for the RX FIFO Any combination of TCP_ADJUST_GIVE_REST_TO_RX ( see page 442), TCP_ADJUST_GIVE_REST_TO_TX ( see page 442), TCP_ADJUST_PRESERVE_RX ( see page 442). TCP_ADJUST_PRESERVE_TX ( see page 443) is not currently supported.
Return Values Return Values TRUE FALSE Description The FIFOs were adjusted successfully Minimum RX, Minimum TX, or flags couldn't be accommodated and therefore the socket was left unchanged.
445
446
If the socket is using SSL, a CLOSE_NOTIFY record will be transmitted first to allow the SSL session to be resumed at a later time. Preconditions None Parameters Parameters hTCP Description Handle of the socket to disconnect.
10.18 TCP
For example, if the buffer contains "I love PIC MCUs!" and the search array is "love" with a length of 4, a value of 2 will be returned. Remarks Since this function usually must transfer data from external storage to internal RAM for comparison, its performance degrades significantly when the buffer is full and the array is not found. For better performance, try to search for characters that are expected to exist or limit the scope of the search as much as possible. The HTTP2 module, for example, uses this function to parse headers. However, it searches for newlines, then the separating colon, then reads the header name to RAM for final comparison. This has proven to be significantly faster than searching for full header name strings outright. Preconditions TCP is initialized. Parameters Parameters hTCP cFindArray wLen wStart wSearchLen bTextCompare Return Values Return Values 0xFFFF Otherwise Description Search array not found Zero-indexed position of the first occurrance Description The socket to search within. The array of bytes to find in the buffer. Length of cFindArray. Zero-indexed starting position within the buffer. Length from wStart to search in the buffer. TRUE for case-insensitive text search, FALSE for binary search
448
10.18 TCP Preconditions TCP is initialized. Parameters Parameters hTCP cFind wStart wSearchLen bTextCompare Return Values Return Values 0xFFFF Otherwise
Description The socket to search within. The byte to find in the buffer. Zero-indexed starting position within the buffer. Length from wStart to search in the buffer. TRUE for case-insensitive text search, FALSE for binary search
Description Search array not found Zero-indexed position of the first occurrance
10.18 TCP
function to parse headers. However, it searches for newlines, then the separating colon, then reads the header name to RAM for final comparison. This has proven to be significantly faster than searching for full header name strings outright. This function is aliased to TCPFindArrayEx ( Preconditions TCP is initialized. Parameters Parameters hTCP cFindArray wLen wStart wSearchLen bTextCompare Return Values Return Values 0xFFFF Otherwise Description Search array not found Zero-indexed position of the first occurrance Description The socket to search within. The array of bytes to find in the buffer. Length of cFindArray. Zero-indexed starting position within the buffer. Length from wStart to search in the buffer. TRUE for case-insensitive text search, FALSE for binary search see page 447) on non-PIC18 platforms.
10.18 TCP C BOOL TCPGet( TCP_SOCKET hTCP, BYTE* byte ); Description Retrieves a single byte to a TCP socket. Preconditions TCP is initialized. Parameters Parameters hTCP byte Return Values Return Values TRUE FALSE
Description The socket from which to read. Pointer to location in which the read byte should be stored.
Description A byte was read from the buffer. The buffer was empty, or the socket is not connected.
451
The SOCKET_INFO ( see page 463) structure associated with this socket. This structure is allocated statically by the function and is valid only until the next time TCPGetRemoteInfo() is called. Description Returns the SOCKET_INFO ( see page 463) structure associated with this socket. This contains the NODE_INFO structure with IP and MAC address (or gateway MAC) and the remote port. Preconditions TCP is initialized and the socket is connected. Parameters Parameters hTCP Description The socket to check.
452
10.18 TCP
453
10.18 TCP Preconditions TCP is initialized. Parameters Parameters hTCP Return Values Return Values TRUE FALSE
Description The socket has an established connection to a remote node. The socket is not currently connected.
If TCP_OPEN_RAM_HOST ( see page 443) or TCP_OPEN_ROM_HOST ( see page 444) are used for the destination type, the DNS client module must also be enabled (STACK_USE_DNS must be defined in TCPIPConfig.h). Preconditions TCP is initialized.
455
// Open a server socket skt = TCPOpen(NULL, TCP_OPEN_SERVER, HTTP_PORT, TCP_PURPOSE_HTTP_SERVER); // Open a client socket to www.microchip.com // The double cast here prevents compiler warnings skt = TCPOpen((DWORD)(PTR_BASE)"www.microchip.com", TCP_OPEN_ROM_HOST, 80, TCP_PURPOSE_DEFAULT); // Reopen a client socket without repeating DNS or ARP SOCKET_INFO cache = TCPGetSocketInfo(skt); // Call with the old socket skt = TCPOpen((DWORD)(PTR_BASE)&cache.remote, TCP_OPEN_NODE_INFO, cache.remotePort.Val, TCP_PURPOSE_DEFAULT); Parameters Parameters dwRemoteHost Description For client sockets only. Provide a pointer to a null-terminated string of the remote host name (ex: "www.microchip.com" or "192.168.1.123"), a literal destination IP address (ex: 0x7B01A8C0 or an IP_ADDR data type), or a pointer to a NODE_INFO structure with the remote IP address and remote node or gateway MAC address specified. If a string is provided, note that it must be statically allocated in memory and cannot be modified or deallocated until TCPIsConnected ( see page 453) returns TRUE. This parameter is ignored for server sockets. Any one of the following flags to identify the meaning of the dwRemoteHost parameter: TCP_OPEN_SERVER ( see page 444) - Open a server socket and ignore the dwRemoteHost parameter. TCP_OPEN_RAM_HOST ( see page 443) - Open a client socket and connect ( see page 168) it to a remote host who's name is stored as a null terminated string in a RAM array. Ex: "www.microchip.com" or "192.168.0.123" (BYTE* type) TCP_OPEN_ROM_HOST ( see page 444) - Open a client socket and connect ( see page 168) it to a remote host who's name is stored as a null terminated string in a literal string or ROM array. Ex: "www.microchip.com" or "192.168.0.123" (ROM BYTE* type) TCP_OPEN_IP_ADDRESS ( see page 443) - Open a client socket and connect ( see page 168) it to a remote IP address. Ex: 0x7B01A8C0 for 192.168.1.123 (DWORD type). Note that the byte ordering is big endian. TCP_OPEN_NODE_INFO ( see page 443) - Open a client socket and connect ( see page 168) it to a remote IP and MAC addresses pair stored in a NODE_INFO structure. dwRemoteHost must be a pointer to the NODE_INFO structure. This option is provided for backwards compatibility with applications built against prior stack versions that only implemented the TCPConnect ( see page 445)() function. It can also be used to skip DNS and ARP resolution steps if connecting to a remote node which you've already connected to and have cached addresses for. wPort TCP port to listen ( see page 172) on or connect ( see page 168) to:
vRemoteHostType
Client sockets - the remote TCP port to which a connection should be made. The local port for client sockets will be automatically picked by the TCP module. Server sockets - the local TCP port on which to listen ( connections. vSocketPurpose see page 172) for
Any of the TCP_PURPOSE_* constants defined in TCPIPConfig.h or the TCPIPConfig utility (see TCPSocketInitializer[] array). 456
10.18 TCP Return Values Return Values INVALID_SOCKET ( Otherwise see page 442)
Description No sockets of the specified type were available to be opened. A TCP_SOCKET ( see page 466) handle. Save this handle and use it when calling all other TCP APIs.
457
Description The socket to peak from (read without removing from stream). Destination to write the peeked data bytes. Length of bytes to peak from the RX FIFO and copy to vBuffer. Zero-indexed starting position within the FIFO to start peeking from.
458
Description The socket to which data is to be written. Pointer to the array to be written. Number of bytes to be written.
459
The return value of this function differs from that of TCPPutArray ( see page 458). To write long strings in a single state, initialize the *data pointer to the first byte, then call this function repeatedly (breaking to the main stack loop after each call) until the return value dereferences to a NUL byte. Save the return value as the new starting *data pointer otherwise. This function is aliased to TCPPutString ( Preconditions TCP is initialized. Parameters Parameters hTCP data Description The socket to which data is to be written. Pointer to the string to be written. see page 460) on non-PIC18 platforms.
10.18 TCP PTR_BASE wSource, BYTE vSourceType, WORD wLength ); Returns None Description
This function copies data between memory mediums (PIC RAM, SPI RAM, and Ethernet buffer RAM). Remarks Copying to a destination region that overlaps with the source address is supported only if the destination start address is at a lower memory address (closer to 0x0000) than the source pointer. However, if they do overlap there must be at least 4 bytes of non-overlap to ensure correct results due to hardware DMA requirements. Preconditions TCP is initialized. Parameters Parameters ptrDest vDestType ptrSource vSourceType wLength Section Function Prototypes Description Address ( Address ( see page 144) to write to see page 144) to copy from Destination meidum (TCP_PIC_RAM, TCP_ETH_RAM, TCP_SPI_RAM) Source medium (TCP_PIC_RAM, TCP_ETH_RAM, or TCP_SPI_RAM) Number of bytes to copy
Description Address ( Address ( see page 144) to write to see page 144) to copy from Destination meidum (TCP_PIC_RAM, TCP_ETH_RAM, TCP_SPI_RAM) Number of bytes to copy
462
10.18 TCP Functions Name TCPInit ( see page 467) see page TCPProcess ( 468) TCPTick (
Description Initializes the TCP module. Handles incoming TCP segments. Performs periodic TCP tasks. Decrypts and MACs data arriving via SSL.
TCPSSLDecryptMAC ( page 469) TCPStartSSLClientEx ( page 469) Module TCP ( see page 439)
Structures Name SOCKET_INFO ( 463) TCB ( see page Description Information about a socket Remainder of TCP Control Block data. The rest of the TCB is stored in Ethernet buffer RAM or elsewhere as defined by vMemoryMedium. Current size is 41 (PIC18), 42 (PIC24/dsPIC), or 48 bytes (PIC32)
TCB_STUB (
see page 465) TCP Control Block (TCB) stub data storage. Stubs are stored in local PIC RAM for speed. Current size is 34 bytes (PIC18), 36 bytes (PIC24/dsPIC), or 56 (PIC32)
Types Name TCP_SOCKET ( 466) Description The following functions and variables are public, but are intended only to be accessed by the stack itself. Applications should generally not call these functions or modify these variables. see page Description A TCP_SOCKET is stored as a single BYTE
463
10.18 TCP
Remainder of TCP Control Block data. The rest of the TCB is stored in Ethernet buffer RAM or elsewhere as defined by vMemoryMedium. Current size is 41 (PIC18), 42 (PIC24/dsPIC), or 48 bytes (PIC32)
10.18 TCP WORD delayedACKTime; WORD closeWaitTime; TCP_STATE smState; unsigned char vUnackedKeepalives : 3; unsigned char bServer : 1; unsigned char bTimerEnabled : 1; unsigned char bTimer2Enabled : 1; unsigned char bDelayedACKTimerEnabled : 1; unsigned char bHalfFullFlush : 1; unsigned char bTXASAP : 1; unsigned char bTXASAPWithoutTimerReset : 1; unsigned char bTXFIN : 1; unsigned char bSocketReset : 1; unsigned char bSSLHandshaking : 1; unsigned char filler : 2; WORD_VAL remoteHash; PTR_BASE sslTxHead; PTR_BASE sslRxHead; BYTE sslStubID; BYTE sslReqMessage; BYTE vMemoryMedium; Description
Microchip TCP/IP Stack Help Delayed Acknowledgement timer TCP_CLOSE_WAIT timeout timer State of this socket
Count of how many keepalives have been sent with no response Socket should return to listening state when closed Timer is enabled Second timer is enabled DelayedACK timer is enabled
unsigned char bOneSegmentReceived : 1; A segment has been received Flush is for being half full Transmit as soon as possible (for Flush) Transmit as soon as possible (for Flush), but do not reset retransmission timers FIN needs to be transmitted Socket has been reset (self-clearing semaphore) Socket is in an SSL handshake Future expansion Consists of remoteIP, remotePort, localPort for connected sockets. It is a localPort number only for listening server sockets. Position of data being written in next SSL application record Also serves as cache of localSSLPort when smState = TCP_LISTENING Position of incoming data not yet handled by SSL Which sslStub ( see page 431) is associated with this connection Currently requested SSL message Which memory medium the TCB is actually stored
TCP Control Block (TCB) stub data storage. Stubs are stored in local PIC RAM for speed. Current size is 34 bytes (PIC18), 36 bytes (PIC24/dsPIC), or 56 (PIC32)
10.18 TCP TCP_GATEWAY_GET_ARP, TCP_LISTEN, TCP_SYN_SENT, TCP_SYN_RECEIVED, TCP_ESTABLISHED, TCP_FIN_WAIT_1, TCP_FIN_WAIT_2, TCP_CLOSING, TCP_CLOSE_WAIT, TCP_LAST_ACK, TCP_CLOSED, TCP_CLOSED_BUT_RESERVED } TCP_STATE; Members Members TCP_GET_DNS_MODULE TCP_DNS_RESOLVE TCP_GATEWAY_SEND_ARP TCP_GATEWAY_GET_ARP TCP_LISTEN TCP_SYN_SENT TCP_SYN_RECEIVED TCP_ESTABLISHED TCP_FIN_WAIT_1 TCP_FIN_WAIT_2 TCP_CLOSING TCP_CLOSE_WAIT TCP_LAST_ACK TCP_CLOSED TCP_CLOSED_BUT_RESERVED Description TCP States as defined by RFC 793
Description Special state for TCP client mode sockets Special state for TCP client mode sockets Special state for TCP client mode sockets Special state for TCP client mode sockets Socket is listening for connections A SYN has been sent, awaiting an SYN+ACK A SYN has been received, awaiting an ACK Socket is connected and connection is established FIN WAIT state 1 FIN WAIT state 2 Socket is closing TCP_TIME_WAIT, state is not implemented Waiting to close the socket The final ACK has been sent Socket is idle and unallocated Special state for TCP client mode sockets. Socket is idle, but still allocated pending application closure of the handle.
467
468
10.18 TCP
469
10.18 TCP Parameters Parameters hTCP host buffer suppDataType Return Values Return Values TRUE FALSE
Description TCP connection to secure Expected host name on certificate (currently ignored) Buffer for supplementary data return Type of supplementary data to copy
Description an SSL connection was initiated Insufficient SSL resources (stubs) were available
FindMatchingSocket ( page 473) HandleTCPSeg ( 473) SendTCP ( SwapTCPHeader ( page 476) SyncTCB ( Macros Name ACK ( FIN ( see page 472) see page 472)
see page
Description Acknowledge Flag as defined in RFC FIN Flag as defined in RFC see see End port for client sockets Starting port for client sockets Push Flag as defined in RFC Reset Flag as defined in RFC see page see page Instead of transmitting normal data, a garbage octet is transmitted according to RFC 1122 section 4.2.3.6 Indicates if this packet is a retransmission (no reset) or a new packet (reset required) SYN Flag as defined in RFC Flushes MyTCBStub ( see page 475) cache and loads up the specified TCB_STUB ( see page 465). Does nothing on cache hit. Timeout before automatically transmitting unflushed data
LOCAL_PORT_START_NUMBER ( page 474) PSH ( RST ( see page 475) see page 475)
SENDTCP_KEEP_ALIVE ( 476)
SENDTCP_RESET_TIMERS ( 476) SYN ( see page 477) see page 477) SyncTCBStub (
TCP_WINDOW_UPDATE_TIMEOUT_VAL Timeout before automatically transmitting a window update due to ( see page 478) a TCPGet ( see page 450)() or TCPGetArray ( see page 451)() function call 470
Microchip TCP/IP Stack Help see see Timeout for the CLOSE_WAIT state
TCP_DELAYED_ACK_TIMEOUT ( page 478) TCP_FIN_WAIT_2_TIMEOUT ( page 479) TCP_KEEP_ALIVE_TIMEOUT ( page 480) TCP_MAX_RETRIES ( TCP_MAX_SEG_SIZE_RX ( 480)
Timeout for delayed-acknowledgement algorithm Timeout for FIN WAIT 2 state Timeout for keep-alive messages when no traffic is sent Maximum number of retransmission attempts TCP Maximum Segment Size for RX. This value is advirtised during connection establishment and the remote node should obey it. This should be set to 536 to avoid IP layer fragmentation from causing packet loss. However, raising its value can enhance performance at the (small) risk of introducing incompatibility with certain special remote nodes (ex: ones connected via a slow dial up modem). TCP Maximum Segment Size for TX. The TX maximum segment size is actually govered by the remote node's MSS option advirtised during connection establishment. However, if the remote node specifies an unhandlably large MSS (ex: > Ethernet MTU), this define sets a hard limit so that we don't cause any TX buffer overflows. If the remote node does not advirtise a MSS option, all TX segments are fixed at 536 bytes maximum. Smaller than all other retries to reduce SYN flood DoS duration Maximum number of keep-alive messages that can be sent without receiving a response before automatically closing the connection For smallest size and best throughput, TCP_OPTIMIZE_FOR_SIZE should always be enabled on PIC24/dsPIC products. On PIC32 products there is very little difference and depnds on compiler optimization level End of List TCP Option Flag Maximum segment size TCP flag
see see
TCP_MAX_SEG_SIZE_TX ( 481)
see page
TCP_MAX_SYN_RETRIES ( 481)
see page
see see
see page 482) No Op TCP Option see page 483) Determines the number of defined TCP sockets see Timeout to retransmit unacked data Number of TCP RX SYN packets to save if they cannot be serviced immediately Timeout for when SYN queue entries are deleted if unserviceable Urgent Flag as defined in RFC
TCP_SYN_QUEUE_MAX_ENTRIES ( see page 484) TCP_SYN_QUEUE_TIMEOUT ( page 484) URG ( Module TCP ( see page 439) see page 484) see
Structures Name TCP_HEADER ( 479) TCP_OPTIONS ( 482) see page see page Description TCP Header Data Structure TCP Options data structure
471
10.18 TCP TCP_SYN_QUEUE ( page 483) Variables Name hCurrentTCP ( 474) MyTCB ( MyTCBStub ( SYNQueue ( TCBStubs ( Description see page see
Structure containing all the important elements of an incomming SYN packet in order to establish a connection at a future time if all sockets on the listening port are already connected to someone
see page 475) Alias to current TCP stub. see page 477) Array of saved incoming SYN requests that need to be serviced later see page 477) This is variable TCBStubs.
The following functions and variables are designated as internal to the TCP module.
472
473
Description The TCP header for this packet The total buffer length of this segment
474
10.18 TCP
Description Additional TCP flags to include Any combinations of SENDTCP_* constants to modify the transmit behavior or contents.
476
10.18 TCP
477
10.18 TCP C
478
4;
1; 1; 1; 1; 1; 1; : 2;
479
10.18 TCP union { struct { unsigned char flagFIN : 1; unsigned char flagSYN : 1; unsigned char flagRST : 1; unsigned char flagPSH : 1; unsigned char flagACK : 1; unsigned char flagURG : 1; unsigned char Reserved2 : 2; } bits; BYTE byte; } Flags; WORD Window; WORD Checksum; WORD UrgentPointer; Description TCP Header Data Structure
10.18 TCP
enhance performance at the (small) risk of introducing incompatibility with certain special remote nodes (ex: ones connected via a slow dial up modem).
10.18 TCP
On PIC32 products there is very little difference and depnds on compiler optimization level
483
10.18 TCP
Variables
10.18.4 Variables
Module TCP ( Variables Name NextPort ( see page 484) Description Tracking variable for next local client port number see page 439)
484
10.19 Telnet
Telnet provides bidirectional, interactive communication between two nodes on the Internet or on a Local Area Network. The Telnet code included with Microchip's TCP/IP stack is a demonstration of the structure of a Telnet application. This demo begins by listening for a Telnet connection. When a client attempts to make one, the demo will prompt the client for a username and password, and if the correct one is provided, will output and periodically refresh several values obtained from the demo board. There are several changes that you may need to make to Telnet.c and/or Telnet.h to suit your application. All of the Telnet Public members can be re-defined in the application-specific section of TCPIPConfig.h. You may also wish to change some of the Telnet Internal Member strings, located in Telnet.c, to more accurately reflect your application. You will also need to modify the TelnetTask ( see page 487) function to include the functionality you'd like. You may insert or change states in TelnetTask ( see page 487) as needed.
MAX_TELNET_CONNECTIONS Number of simultaneously allowed Telnet ( see page 485) sessions. Note ( see page 485) that you must have an equal number of TCP_PURPOSE_TELNET type TCP sockets declared in the TCPSocketInitializer[] array above for multiple connections to work. If fewer sockets are available than this definition, then the the lesser of the two quantities will be the actual limit. TELNET_PASSWORD ( page 486) TELNET_PORT ( 486) TELNETS_PORT ( 486) see Default Telnet ( see page 485) password see page 485) server. Port 23 is
Default local listening port for the Telnet ( the protocol default.
Default local listening port for the Telnet ( see page 485) server when SSL secured. Port 992 is the telnets protocol default. Default username and password required to login to the Telnet ( 485) server. see page
The following functions and variables are available to the stack application.
485
10.19 Telnet C
#define MAX_TELNET_CONNECTIONS (1u) Description Number of simultaneously allowed Telnet ( see page 485) sessions. Note that you must have an equal number of TCP_PURPOSE_TELNET type TCP sockets declared in the TCPSocketInitializer[] array above for multiple connections to work. If fewer sockets are available than this definition, then the the lesser of the two quantities will be the actual limit.
486
10.19 Telnet
Microchip TCP/IP Stack Help see page 488) Demo disconnection message see page
DO Suppress Local Echo (stop telnet client from printing typed characters) Access denied message Demo title string
The following functions and variables are designated as internal to the Telnet (
488
10.20 TFTP
The Trivial File Transfer Protocol provides unreliable upload and download services to applications connected to the UDP-based TFTP server.
489
10.20 TFTP
see page
490
10.20 TFTP _TFTP_RESULT ( page 500) Functions Name TFTPCloseFile ( TFTPGet ( see page 492) see
Microchip TCP/IP Stack Help Enum. of results returned by most of the TFTP functions.
Description Sends file closing messages. Gets a data byte from data that was read. Determines if the file was closed. Determines if file has been opened. Determines if a data block is ready to be read. Determines if the TFTP connection is open. Determines if data can be written to a file. Initializes TFTP module. Prepares and sends TFTP file name and mode packet. PIC18 ROM argument implementation of TFTPOpenFile ( page 498) Write a byte to a file. see
see page 493) see page 494) see page 494) see page 495) see page 496) see page 496)
TFTPOpenFile (
TFTPOpenROMFile ( TFTPPut (
TFTPGetUploadStatus (
see page 500) Returns the TFTP file upload status started by calling the TFTPUploadRAMFileToHost ( see page 502)() or TFTPUploadFragmentedRAMFileToHost ( see page 501)() functions.
TFTPUploadFragmentedRAMFileToHost Uploads an random, potentially non-contiguous, array of RAM bytes ( see page 501) as a file to a remote TFTP server. TFTPUploadRAMFileToHost ( page 502) Macros Name TFTPClose ( see page 492) see page 493) see page 495) Description Macro: void TFTPClose(void) Closes TFTP client socket. Macro: WORD TFTPGetError(void) Returns previously saved error code. Macro: BOOL TFTPIsFileOpenReady(void) Checks to see if it is okay to send TFTP file open request to remote server. Status codes for TFTPGetUploadStatus ( see page 500)() function. Zero means upload success, >0 means working and <0 means fatal error. see Uploads a contiguous array of RAM bytes as a file to a remote TFTP server.
TFTPGetError (
TFTPIsFileOpenReady (
see page
see page 503) This is macro TFTP_UPLOAD_CONNECT. This is macro TFTP_UPLOAD_CONNECT_TIMEOUT. This is macro TFTP_UPLOAD_GET_DNS.
TFTP_UPLOAD_HOST_RESOLVE_TIMEOUT This is macro TFTP_UPLOAD_HOST_RESOLVE_TIMEOUT. ( see page 504) TFTP_UPLOAD_RESOLVE_HOST ( page 504) see This is macro TFTP_UPLOAD_RESOLVE_HOST.
491
This is macro TFTP_UPLOAD_SEND_DATA. This is macro TFTP_UPLOAD_SEND_FILENAME. This is macro TFTP_UPLOAD_SERVER_ERROR. This is macro TFTP_UPLOAD_WAIT_FOR_CLOSURE.
TFTP_UPLOAD_WAIT_FOR_CLOSURE ( see page 505) Module TFTP ( Structures Name Description see page 489)
TFTP_CHUNK_DESCRIPTOR This is type TFTP_CHUNK_DESCRIPTOR. ( see page 502) Description The following functions and variables are available to the stack application.
If TFTP server does not change during application life-time, one may not need to call TFTPClose and keep TFTP socket open. Preconditions TFTPOpen ( see page 497) is already called and TFTPIsOpened ( see page 496)() returned TFTP_OK.
492
If file is opened in read mode, it makes sure that last ACK is sent to server If file is opened in write mode, it makes sure that last block is sent out to server and waits for server to respond with ACK. Remarks TFTPIsFileClosed ( Preconditions TFTPOpenFile ( see page 498)() was called and TFTPIsFileOpened ( see page 494)() had returned with TFTP_OK. see page 494)() must be called to confirm if file was really closed.
493
10.20 TFTP Description Macro: WORD TFTPGetError(void) Returns previously saved error code. Remarks None Preconditions
494
TFTP_RETRY if previous attempt was timed out needs to be retried. TFTP_TIMEOUT if all attempts were exhausted. TFTP_ERROR if remote server responded with error TFTP_NOT_READY if file is not yet opened. Description Waits for remote server response regarding previous attempt to open file. If no response is received within specified timeout, fnction returns with TFTP_RETRY and application logic must issue another TFTPFileOpen(). Remarks None Preconditions TFTPOpenFile ( see page 498)() is called.
495
TFTP_OK if it there is more data byte available to read TFTP_TIMEOUT if timeout occurred waiting for new data. TFTP_END_OF_FILE if end of file has reached. TFTP_ERROR if remote server returned ERROR. Actual error code may be read by calling TFTPGetError ( 493)() TFTP_NOT_READY if still waiting for new data. Description Waits for data block. If data block does not arrive within specified timeout, it automatically sends out ack for previous block to remind server to send next data block. If all attempts are exhausted, it returns with TFTP_TIMEOUT. Remarks By default, this funciton uses "octet" or binary mode of file transfer. Preconditions TFTPOpenFile ( see page 498)() is called with TFTP_FILE_MODE_READ and TFTPIsFileOpened ( returned with TRUE. see page 494)() see page
TFTP_TIMEOUT if remote host did not respond to previous ARP request. TFTP_NOT_READY if remote has still not responded and timeout has not expired. Description Waits for ARP reply and opens a UDP socket to perform further TFTP operations. Remarks Once opened, application may keep TFTP socket open and future TFTP operations. If TFTPClose ( see page 492)() is called to close the connection TFTPOpen ( see page 497)() must be called again before performing any other TFTP operations. Preconditions TFTPOpen ( see page 497)() is already called.
496
10.20 TFTP C TFTP_RESULT TFTPIsPutReady(); Side Effects None Returns TFTP_OK if it is okay to write more data byte.
TFTP_TIMEOUT if timeout occurred waiting for ack from server TFTP_RETRY if all server did not send ack on time and application needs to resend last block. TFTP_ERROR if remote server returned ERROR. Actual error code may be read by calling TFTPGetError ( 493)() TFTP_NOT_READY if still waiting... Description Waits for ack from server. If ack does not arrive within specified timeout, it it instructs application to retry last block by returning TFTP_RETRY. If all attempts are exhausted, it returns with TFTP_TIMEOUT. Remarks None Preconditions TFTPOpenFile ( see page 498)() is called with TFTP_FILE_MODE_WRITE and TFTPIsFileOpened ( returned with TRUE. see page 494)() see page
497
498
10.20 TFTP
499
10.20 TFTP C typedef enum _TFTP_FILE_MODE { TFTP_FILE_MODE_READ = 1, TFTP_FILE_MODE_WRITE = 2 } TFTP_FILE_MODE; Description File open mode as used by TFTPFileOpen().
It is only possible to have one TFTP operation active at any given time. After starting a TFTP operation by calling TFTPUploadRAMFileToHost ( see page 502)() or TFTPUploadFragmentedRAMFileToHost(), you must wait until TFTPGetUploadStatus ( see page 500)() returns a completion status code (<=0) before calling any other TFTP API functions. Preconditions None Parameters Parameters vRemoteHost Description ROM string of the remote TFTP server to upload to (ex: "www.myserver.com"). For device architectures that make no distinction between RAM and ROM pointers (PIC24, dsPIC and PIC32), this string must remain allocated and unmodified in RAM until the TFTP upload process completes (as indicated by TFTPGetUploadStatus ( see page 500)()). ROM string of the remote file to create/overwrite (ex: "status.txt"). For device architectures that make no distinction between RAM and ROM pointers (PIC24, dsPIC and PIC32), this string must remain allocated and unmodified in RAM until the TFTP upload process completes (as indicated by TFTPGetUploadStatus ( see page 500)()). Pointer to a static or global (persistent) array of TFTP_CHUNK_DESCRIPTOR ( see page 502) structures describing what RAM memory addresses the file contents should be obtained from. The TFTP_CHUNK_DESCRIPTOR.vDataPointer field should be set to the memory address of the data to transmit, and the TFTP_CHUNK_DESCRIPTOR.wDataLength field should be set to the number of bytes to transmit from the given pointer. The TFTP_CHUNK_DESCRIPTOR ( see page 502) array must be terminated by a dummy descriptor whos TFTP_CHUNK_DESCRIPTOR.vDataPointer pointer is set to NULL. Refer to the TFTPUploadRAMFileToHost ( see page 502)() API for an example calling sequence since it merely a wrapper to this TFTPUploadFragmentedRAMFileToHost() function.
vFilename
vFirstChunkDescriptor
501
10.20 TFTP
It is only possible to have one TFTP operation active at any given time. After starting a TFTP operation by calling TFTPUploadRAMFileToHost() or TFTPUploadFragmentedRAMFileToHost ( see page 501)(), you must wait until TFTPGetUploadStatus ( see page 500)() returns a completion status code (<=0) before calling any other TFTP API functions. Preconditions None Parameters Parameters vRemoteHost Description ROM string of the remote TFTP server to upload to (ex: "www.myserver.com"). For device architectures that make no distinction between RAM and ROM pointers (PIC24, dsPIC and PIC32), this string must remain allocated and unmodified in RAM until the TFTP upload process completes (as indicated by TFTPGetUploadStatus ( see page 500)()). ROM string of the remote file to create/overwrite (ex: "status.txt"). For device architectures that make no distinction between RAM and ROM pointers (PIC24, dsPIC and PIC32), this string must remain allocated and unmodified in RAM until the TFTP upload process completes (as indicated by TFTPGetUploadStatus ( see page 500)()). Pointer to a RAM array of data to write to the file. Number of bytes pointed to by vData. This will be the final file size of the uploaded file. Note that since this is defined as a WORD type, the maximum possible file size is 65535 bytes. For longer files, call the TFTPUploadFragmentedRAMFileToHost ( see page 501)() function instead.
vFilename
vData wDataLength
10.20 TFTP BYTE * vDataPointer; WORD wDataLength; } TFTP_CHUNK_DESCRIPTOR; Description This is type TFTP_CHUNK_DESCRIPTOR.
503
10.20 TFTP
504
10.20 TFTP C
Description The following functions and variables are public, but are intended only to be accessed by the stack itself. Applications should generally not call these functions or modify these variables.
505
10.20 TFTP
see page
see Private helper function PIC18 ROM variable argument implementation of _TFTPSendFileName ( page 510) see
_TFTPSendROMFileName ( see page 511) Macros Name TFTP_BLOCK_SIZE ( page 508) see
Description The size of a TFTP block - 512 bytes The MSB of the TFTP_BLOCK_SIZE ( see page 508)
TFTP_BLOCK_SIZE_MSB ( see page 508) TFTP_CLIENT_PORT ( see page 508) TFTP_SERVER_PORT ( see page 509)
The TFTP Client port - a unique port on this device The TFTP Server Port
506
10.20 TFTP Module TFTP ( Variables Name MutExVar ( _tftpError ( _tftpFlags ( _tftpRetries ( _tftpSocket ( _tftpStartTick ( _tftpState ( smUpload ( see page 507) see page 509) see page 509) see page 510) see page 511) see page 511) see page 489)
Description Mutually Exclusive variable groups to conserve RAM. Variable to preserve error condition causes for later transmission TFTP status flags Tracker variable for the number of TFTP retries TFTP Socket for TFTP server link Timing variable used to detect timeout conditions TFTP state machine tracker variable This is variable smUpload. This is variable uploadChunkDescriptor.
uploadChunkDescriptor ( 512)
uploadChunkDescriptorForRetransmit This is variable uploadChunkDescriptorForRetransmit. ( see page 512) vUploadFilename ( see page 512) see page This is variable vUploadFilename. TFTPUploadRAMFileToHost ( see page 502)(), TFTPUploadFragmentedRAMFileToHost ( see page 501)() and TFTPGetUploadStatus ( see page 500)() functions require the DNS client module to be enabled for them to work. The RAM and ROM resources for these functions can be preserved if the DNS client module isn't enabled. This is variable wUploadChunkOffset. This is variable wUploadChunkOffsetForRetransmit. vUploadRemoteHost ( 512)
wUploadChunkOffset ( 513)
see page
The following functions and variables are designated as internal to the TFTP module.
507
10.20 TFTP
509
10.20 TFTP C union { struct { unsigned int unsigned int unsigned int unsigned int unsigned int } bits; BYTE Val; } _tftpFlags; Description TFTP status flags
510
10.20 TFTP
10.20 TFTP C
512
see page 517) functions the Tick is suitable for measuring time increments from a few microseconds
If absolute timestamps are required, the SNTP Client module may be more appropriate.
Description The following functions and variables are available to the stack application.
514
data to a user). For timeout comparisons, compare the current value to a multiple or fraction of TICK_SECOND ( 515), which will be calculated only once at compile time. Preconditions None Parameters Parameters dwTickValue Description Value to convert to milliseconds
516
517
see page
The following functions and variables are designated as internal to the Tick module.
10.22 UDP C
volatile DWORD dwInternalTicks = 0; Description Internal counter to store Ticks. This variable is incremented in an ISR and therefore must be marked volatile to prevent the compiler optimizer from reordering code to use this value in the main context while interrupts are disabled.
519
10.22 UDP
10.22 UDP
Types Name UDP_STATE ( 540) Description UDP is a standard transport layer protocol described in RFC 768. It provides fast but unreliable data-gram based transfers over networks, and forms the foundation SNTP, SNMP, DNS, and many other protocol standards. Connections over UDP should be thought of as data-gram based transfers. Each packet is a separate entity, the application should expect some packets to arrive out-of-order or even fail to reach the destination node. This is in contrast to TCP, in which the connection is thought of as a stream and network errors are automatically corrected. These tradeoffs in reliability are made for an increase in throughput. In general, UDP transfers operate 2 to 3 times faster than those made over TCP. Since UDP is packet-oriented, each packet must be dealt with in its entirety by your application before returning to the main stack loop. When a packet is received, your application will be called to handle it. This packet will no longer be available the next time your application is called, so you must either perform all necessary processing or copy the data elsewhere before returning. When transmitting a packet, your application must build and transmit the complete packet in one cycle. The UDP flow diagram below provides an overview for the use of the UDP module: see page Description UDP States
Sockets ( see page 149) are opened using UDPOpen ( see page 524). This function can either open a listening socket to wait for incoming segments, or can make a client connection to a remote node. When making a client connection, you will need to perform any required DNS and/or ARP resolution using those modules directly before invoking UDPOpen ( see page 524). Once the socket is opened, you can immediately begin transmitting data. To transmit a segment, call UDPIsPutReady ( see page 528) to determine how many bytes can be written and to designate a currently active socket. Then, use any of the UDPPut ( see page 528) family of functions to write data to the socket. Once all data has been written, call UDPFlush ( see page 526) to build and transmit the packet. This sequence must be accomplished all in one step. If your application returns to the main stack loop after calling UDPPut ( see page 528) but before calling UDPFlush ( see page 526), the data may be lost or the module may behave unpredictably. 520
10.22 UDP
To check for received segments, call UDPIsGetReady ( see page 527). If the return value is non-zero, your application must consume the segment by reading data with the UDPGet ( see page 526) family. Once all data has been read, return to the main stack loop to wait for an additional segment. UDP segments are only stored for one iteration of the cooperative multi-tasking loop, so your application must complete its processing on a segment or copy it elsewhere before returning. Note that this behavior differs from TCP, which buffers incoming data through multiple stack cycles. When a socket is no longer needed, call UDPClose ( see page 525) to release it back to the pool for future use.
see page 525) see page see page 526) see page 526) see page
UDPGetArray ( 527)
see page Determines how many bytes can be read from the UDP socket. see page Determines how many bytes can be written to the UDP socket. Writes a byte to the currently active socket. Writes an array of bytes to the currently active socket. Writes an array of bytes from ROM to the currently active socket. Writes null-terminated string from ROM to the currently active socket. Writes null-terminated string to the currently active socket. Moves the pointer within the RX buffer.
see page Moves the pointer within the TX buffer. see page Determines if a socket has an established connection.
Description see Indicates a UDP port that is not valid Indicates a UDP socket that is not valid Macro of the legacy version of UDPOpen. Create a client socket and use dwRemoteHost as a literal IP address. Create a client socket and use dwRemoteHost as a pointer to a NODE_INFO structure containing the exact remote IP address and MAC address to use.
INVALID_UDP_SOCKET ( see page 522) UDPOpen ( see page 524) UDP_OPEN_IP_ADDRESS ( see page 532) UDP_OPEN_NODE_INFO ( see page 532)
521
10.22 UDP UDP_OPEN_RAM_HOST ( see page 533) UDP_OPEN_ROM_HOST ( see page 533) UDP_OPEN_SERVER ( see page 533) Module UDP ( Types Name UDP_SOCKET ( 522) Description see page see page 520)
Emit an undeclared identifier diagnostic if code tries to use UDP_OPEN_RAM_HOST while the DNS client module is not enabled. Emit an undeclared identifier diagnostic if code tries to use UDP_OPEN_ROM_HOST while the DNS client module is not enabled. Create a server socket and ignore dwRemoteHost.
The following functions and variables are available to the stack application.
522
10.22 UDP
523
Any one of the following flags to identify the meaning of the remoteHost parameter: UDP_OPEN_SERVER ( see page 533) = Open a server socket and ignore the remoteHost parameter. (e.g. - SNMP agent, DHCP server, Announce ( see page 152)) UDP_OPEN_IP_ADDRESS ( see page 532) = Open a client socket and connect ( see page 168) it to a remote IP address. Ex: 0x7B01A8C0 for 192.168.1.123 (DWORD type). Note that the byte ordering is big endian. UDP_OPEN_NODE_INFO ( see page 532) = Open a client socket and connect ( see page 168) it to a remote IP and MAC addresses pair stored in a NODE_INFO structure. UDP_OPEN_RAM_HOST ( see page 533) = Open a client socket and connect ( see page 168) it to a remote host who's name is stored as a null terminated string in a RAM array. Ex:"www.microchip.com" or "192.168.0.123" UDP_OPEN_ROM_HOST ( see page 533) = Open a client socket and connect ( see page 168) it to a remote host who's name is stored as a null terminated string in a literal string or ROM array. Ex: "www.microchip.com" or "192.168.0.123"
UDP port number to listen ( see page 172) on. If 0, stack will dynamically assign a unique port number to use. For client sockets, the remote port number.
Description A UDP socket handle that can be used for subsequent UDP API calls. INVALID_UDP_SOCKET ( see page 522). This function fails when no more UDP socket handles are available. Increase MAX_UDP_SOCKETS to make more sockets available.
524
Pointer to remote node info (MAC and IP address) for this connection. If this is a server socket (receives the first packet) or the destination is the broadcast address, then this parameter should be NULL. For client sockets, the remote port number.
Description A UDP socket handle that can be used for subsequent UDP API calls. INVALID_UDP_SOCKET ( see page 522). This function fails when no more UDP socket handles are available. Increase MAX_UDP_SOCKETS to make more sockets available.
Closes a UDP socket and frees the handle. Call this function to release a socket and return it to the pool for use by future communications. Remarks This function does not affect the previously designated active socket. Preconditions UDPInit ( Parameters Parameters s Description The socket handle to be released. If an illegal handle value is provided, the function safely does nothing. see page 534)() must have been previously called.
It is safe to call this function more than is necessary. If no data is available, this function does nothing. Preconditions UDPIsGetReady ( see page 527)() was previously called to select the currently active socket.
wDateLen
527
10.22 UDP
528
10.22 UDP
529
Description The array to write to the socket. Number of bytes from cData to be written.
530
531
10.22 UDP
Return Values Return Values TRUE FALSE Description The socket has been opened and ARP has been resolved. The socket is not currently connected.
532
10.22 UDP
Description The following functions and variables are public, but are intended only to be accessed by the stack itself. Applications should generally not call these functions or modify these variables. 533
10.22 UDP
534
10.22 UDP
LOCAL_UDP_PORT_START_NUMBER First port number for randomized local port number selection ( see page 537) Module UDP ( see page 520)
Structures Name UDP_HEADER ( 538) see page Description Stores the header of a UDP packet
UDP_SOCKET_INFO ( page 538) Types Name UDP_PORT ( 538) Variables Name activeUDPSocket ( page 536) see see page
535
Microchip TCP/IP Stack Help Indicates the last socket to which data was written
SocketWithRxData ( page 537) UDPRxCount ( 539) UDPSocketInfo ( 539) UDPTxCount ( 539) wGetOffset ( wPutOffset ( Description
Indicates which socket has currently received data for this loop Number of bytes read from this UDP segment Stores an array of information pertaining to each UDP socket Number of bytes written to this UDP segment
see page 539) Offset from beginning of payload from where data is to be read. see page 540) Offset from beginning of payload where data is to be written.
The following functions and variables are designated as internal to the UDP module.
536
537
10.22 UDP
538
10.22 UDP Members Members NODE_INFO remoteNode; DWORD remoteHost; UDP_PORT remotePort; UDP_PORT localPort; UDP_STATE smState; unsigned char bRemoteHostIsROM : 1; Description
Description 10 bytes for MAC and IP address RAM or ROM pointer to a hostname string (ex: "www.microchip.com") Remote node's UDP port number Local UDP port number, or INVALID_UDP_PORT ( State of this socket Remote host is stored in ROM see page 522) when free
539
Types
10.22.4 Types
Enumerations Name UDP_STATE ( 540) Module UDP ( see page 520) see page Description UDP States
11
11 Wi-Fi API
Modules Name Wi-Fi Connection Profile ( Wi-Fi Connection Algorithm ( 558) Wi-Fi Connection Manager ( 580) Wi-Fi Scan ( see page 582) see page 584) see page 586) see page 591) Wi-Fi Tx Power Control ( Wi-Fi Power Save ( Wi-Fi Miscellaneous ( Description Unlike Ethernet, a WiFi application needs to initiate a connection to an access point or an ad hoc network) before data communications can commence. In order to initiate an connection there is a sequence of steps that should be followed. see page see page Description see page 544) Functions to setup, use, and teardown connection profiles Functions to alter the behavior of the connection process Functions to manage the connection process Functions to direct the MRF24WB0M to initiate a site survey API to control the Tx power of the MRF24WB0M Functions to alter the power savings features of the MRF24WB0M Functions for controlling miscellaneous features of the MRF24WB0M
1) A connection profile must be created (see WF_CPCreate ( see page 545)()). The connection profile contains information directing the WiFi driver about the nature of the connection that will be established. The connection profile defines: a. SSID (name of Access Point) b. Security (open, WEP, WPA, etc.) c. Network type (infrastructure or ad hoc).
The Connection Profile functions are used to create and define an connection profile. These functions all begin with WF_CP
2) The connection algorithm must be defined, and applies to all connection profiles. For most applications the defaults will be sufficient. For example, the default connection algorithm channel list for scanning is 1, 6, and 11. However, if, in your application you know the Access Point will always be on channel 6 you could change this setting, thus making the scan process more efficient. Functions pertaining to the connection algorithm all begin with WF_CA
3) Once a connection profile and the connection algorithm are customized for an application, the WF_CMConnect ( page 580)() function must be called to initiate the connection process.
see
4) After WF_Connect() is called the host application will be notified when the MRF24WB0M has succeeded (or failed) in establishing a connection via the event mechanism. The WF_Config.c file has a function, WF_ProcessEvent ( see page 599)(), that is a template for processing MRF24WB0M events. In the WiFi demos it simply prints to the console (if the UART is enabled) that the event occurred. This file can be modified to suit the needs of an application for example, an application could pend on a global flag that would be set in WF_ProcessEvent ( see page 599)() when the connection succeeded. Please refer to WF_ProcessEvent ( see page 599) for more information on WiFi event handling.
The MRF2WB0M demos (under the Demo App, WiFi Console, and WiFi EZ Config demo directories) contain a function, WF_Connect(), in MainDemo.c that executes the above steps and can be referred to as an example of how to initiate a WiFi 541
11
Microchip TCP/IP Stack Help connection. The WF_Config.h file has MY_DEFAULT_SSID_NAME) as needed. several compile-time constants that can be customized (e.g.
This help file book describes the host API to the MRF24WB0M on-chip connection manager which creates and maintains Wi-Fi connections. The API is divided into these major sections: API Section Initialization ( 135) Description see page Functions to initialize the host API and MRF24WB0M Functions to create and maintain one or more connection profiles Functions to fine tune the connection algorithm Functions to start and stop an 802.11 connection Functions to scan for wireless networks Functions to control the MRF24WB0M Tx power Functions to save power consumption by the MRF24WB0M Functions to create multicast filters Functions to set a custom MAC address, get device information, etc. Functions to handle events from the MRF24WB0M
Connection Profile Connection Algorithm Connection Manager Scan Tx Power Control Power Save Multicast Miscellaneous MRF24WB0M Events
SPI The WF_Spi.c file contains functions that the Wi-Fi Driver will use to initialize, send, and receive SPI messages between the host CPU and the MRF24WB0M. To communicate with the MRF24WB0M, which is always an SPI slave, the host CPU SPI controller needs to be configured as follows: Mode = 0 CPOL (clock polarity) = 0 CPHA (clock phase) = 0 Host CPU set as master Clock idles high 8-bit transfer length Data changes on falling edge Data sampled on rising edge Below is a list of functions in WF_Spi.c that must be customized for the specific host CPU architecture: Function WF_SpiInit() WF_SpiTxRx() WF_SpiEnableChipSelect() Description Initializes the host CPU SPI controller for usage by the Wi-Fi driver. Called by the Wi-Fi driver during initialization. Transmits and/or receives SPI data from the MRF24WB0M. Set slave select line on MRF24WB0M low (start SPI transfer). If SPI bus is shared with any other devices then this function also needs to save the current SPI context and then configure the MRF24WB0M SPI context. WF_SpiDisableChipSelect() Set slave select line on MRF24WB0M high (end SPI transfer). If SPI bus is shared with any other devices then this function also needs to restore the SPI context (saved during WF_SpiEnableChipSelect()).
542
11
External Interrupt The WF_Eint.c file contains functions that the Wi-Fi Driver will use to enable and disable the MRF24WB0M external interrupt as well as get interrupt status. The functions in this module need to be customized for the specific host CPU architecture. The MRF24WB0M asserts its EXINT (external interrupt) line (active low) when specific events occur, such as a data message being received. Note that the host CPU has a choice to either configure the EXINT line to generate an actual interrupt, or, it can be polled. Below is a list of the Wi-Fi Driver functions within WF_Eint.c that must be customized for the specific Host CPU architecture. Function WF_EintInit() Description Configures the interrupt for use and leaves it in a disabled state. Will be called by the Wi-Fi driver during initialization. If polling the EXINT pin then this function wont have any work to do except leave the interrupt in a logically disabled state. Enables the MRF24WB0M external interrupt. If using real interrupts then enable the interrupt. If polling the EXINT pin then this function enables polling of the pin. Disables the MRF24WB0M external interrupt. If using real interrupts then disable the interrupt. If polling the EXINT pin then this function disables polling of the pin. This is the interrupt service routine invoked when the EXINT line goes low. It should perform any necessary housekeeping , such as clearing the interrupt. The interrupt must remain disabled until the Wi-Fi Driver calls WF_EintEnable(). The Wi-Fi driver function, WFEintHandler() must be called. Returns true if the external interrupt is disabled, else returns false. This function does not need to be customized it is part of the Wi-Fi driver. However, it is added to this list because it must be called each time the MRF24WB0M interrupt service routine (ISR) occurs.
WF_EintIsDisabled() WFEintHandler()
WF_Config The WF_Config module (WF_Config.h/WF_Config.c) is used to control several aspects of the WiFi Driver behavior. Most of the customization of the Wi-Fi module is done from the context of this module. Removal of Unused Driver Functions In WF_Customize.h there is a block of defines that can be commented out to remove those sections of the Wi-Fi host driver that are not needed by the application. This allows the saving of code and data space. #define WF_USE_SCAN_FUNCTIONS WF_USE_TX_POWER_CONTROL_FUNCTIONS WF_USE_POWER_SAVE_FUNCTIONS WF_USE_MULTICAST_FUNCTIONS WF_USE_INDIVIDUAL_SET_GETS Controlling Functions Scan API Tx power control API Power save API Multicast API Affects all get and set functions, except the following: WF_CPSetElements ( see page 553)() WF_CPGetElements ( see page 548)() WF_CASetElements ( see page 570)() WF_CAGetElements ( see page 562)() Affects the following functions: WF_CPSetElements ( see WF_CPGetElements ( see WF_CASetElements ( see WF_CAGetElements ( see page page page page 553)() 548)() 570)() 562)()
WF_USE_GROUP_SET_GETS
543
WF_DEBUG This define enables the WF_ASSERT macro in the Wi-Fi driver. Customer code is free to use this macro. The WF_ASSERT macro can be compiled in or out via the WF_DEBUG define. See the comment above the WF_DEBUG define in WF_Customize.h for details. WF_CONSOLE The Wi-Fi driver has a UART console application built in that allows one to type in command lines and has them parsed. If this functionality is not needed than it can be compiled out by commenting out the WF_CONSOLE define. WF_ProcessEvent() This function is called by the Wi-Fi Driver when an event occurs that the host CPU needs to be notified of. There are several Wi-Fi connection related events that the application can choose whether to be notified or not. And, there are several events the application will always be notified of. The function WF_ProcessEvent ( see page 599)() can be customized to support desired handling of events.
544
WF_CPGetDefaultWepKeyIndex Gets the value of the active WEP keys to use. ( see page 547) WF_CPGetElements ( page 548) WF_CPGetIds ( see Reads the Connection Profile elements for the specified ID.
see page 548) Retrieves the CP ID bit mask. see Gets the network for the specified Connection Profile ID.
see page Gets the security for the specified Connection Profile. Gets the SSID for the specified Connection Profile ID. Selects the desired Ad Hoc behavior Sets the BSSID for the specified Connection Profile ID.
see page
WF_CPSetDefaultWepKeyIndex Selects one of the 4 WEP keys to use. ( see page 552) WF_CPSetElements ( page 553) see see Writes out data for a specific connection profile element. Sets the network for the specified Connection Profile ID.
WF_CPSetNetworkType ( page 553) WF_CPSetSecurity ( 554) WF_CPSetSsid ( 555) Module Wi-Fi Connection Profile ( Structures Name WFCPElementsStruct ( page 555) Description
see page Sets the security for the specified Connection Profile. Sets the SSID for the specified Connection Profile ID.
see page
The ID returned by this function is used in other connection profile functions. A maximum of 2 Connection Profiles can exist on the MRF24WB0M. Remarks None. Preconditions MACInit must be called first. Parameters Parameters p_CpId Description Pointer to where Connection Profile ID will be written. If function fails, the CP ID will be set to 0xff.
546
Gets the AdHoc behavior within a Connection Profile. Allowable values are: WF_ADHOC_CONNECT_THEN_START WF_ADHOC_CONNECT_ONLY WF_ADHOC_START_ONLY Remarks None. Preconditions MACInit must be called first. Parameters Parameters CpId adHocBehavior Description Connection Profile ID Pointer to location of the adhoc behavior value for this connection profile.
Only applicable if the Connection Profile security type is either WF_SECURITY_WEP_40 or WF_SECURITY_WEP_104. Selects which of the four WEP keys to use. Remarks Note that only key 0 amongst AP manufacturers is typically used. Using any of the other three keys may be unpredictable from brand to brand. Preconditions MACInit must be called first. Parameters Parameters CpId p_defaultWepKeyIndex Description Connection Profile ID Pointer to index of WEP key to use (0 - 3)
548
11.1 Wi-Fi Connection Profile C void WF_CPGetIds( UINT8 * cpIdList ); Returns None. Description
Returns a list of all Connection Profile IDs that have been created on the MRF24WB0M. This is not to be confused with the Connection Algorithms connectionProfileList. This function returns a bit mask corresponding to a list of all Connection Profiles that have been created (whether they are in the connectionProfileList or not). Any Connection Profiles that have been saved to FLASH will be included. Remarks the first release will only support two Connection Profiles in memory. Saving CPs to FLASH will not be supported. None. Preconditions MACInit must be called first. Parameters Parameters p_cpIdList Description Pointer to value representing the bit mask where each bit index (plus 1) corresponds to a Connection Profile ID that has been created. For example, if this value is 0x03, then Connection Profile IDs 1 and and 2 have been created.
549
Security WF_SECURITY_OPEN WF_SECURITY_WEP_40 WF_SECURITY_WEP_104 WF_SECURITY_WPA_WITH_KEY WF_SECURITY_WPA_WITH_PASS_PHRASE WF_SECURITY_WPA2_WITH_KEY WF_SECURITY_WPA2_WITH_PASS_PHRASE WF_SECURITY_WPA_AUTO_WITH_KEY WF_SECURITY_WPA_AUTO_WITH_PASS_PHRASE Remarks None. Preconditions MACInit must be called first. Parameters Parameters CpId securityType wepKeyIndex p_securityKey securityKeyLength Description Connection Profile ID
Key N/A hex hex hex ascii hex ascii hex ascii
Length N/A 4, 5 byte keys 4, 13 byte keys 32 bytes 8-63 ascii characters 32 bytes 8-63 ascii characters 32 bytes 8-63 ascii characters
Value corresponding to the security type desired. 0 thru 3 (only used if security type is WF_SECURITY_WEP_40 or WF_SECURITY_WEP_104) Binary key or passphrase (not used if security is WF_SECURITY_OPEN) Number of bytes in p_securityKey (not used if security is WF_SECURITY_OPEN)
550
Description Connection Profile ID Value of the adhoc behavior for this connection profile.
552
11.1 Wi-Fi Connection Profile Preconditions MACInit must be called first. Parameters Parameters CpId defaultWepKeyIndex
553
11.1 Wi-Fi Connection Profile WF_ADHOC Remarks None. Preconditions MACInit must be called first. Parameters Parameters CpId networkType
Security WF_SECURITY_OPEN WF_SECURITY_WEP_40 WF_SECURITY_WEP_104 WF_SECURITY_WPA_WITH_KEY WF_SECURITY_WPA_WITH_PASS_PHRASE WF_SECURITY_WPA2_WITH_KEY WF_SECURITY_WPA2_WITH_PASS_PHRASE WF_SECURITY_WPA_AUTO_WITH_KEY WF_SECURITY_WPA_AUTO_WITH_PASS_PHRASE Remarks None. Preconditions MACInit must be called first.
Key N/A hex hex hex ascii hex ascii hex ascii
Length N/A 4, 5 byte keys 4, 13 byte keys 32 bytes 8-63 ascii characters 32 bytes 8-63 ascii characters 32 bytes 8-63 ascii characters
554
11.1 Wi-Fi Connection Profile Parameters Parameters CpId securityType wepKeyIndex p_securityKey securityKeyLength
Description Connection Profile ID Value corresponding to the security type desired. 0 thru 3 (only used if security type is WF_SECURITY_WEP_40 or WF_SECURITY_WEP_104) Binary key or passphrase (not used if security is WF_SECURITY_OPEN) Number of bytes in p_securityKey (not used if security is WF_SECURITY_OPEN)
11.1 Wi-Fi Connection Profile UINT8 wepDefaultKeyId; UINT8 networkType; UINT8 adHocBehavior; }; Members Members UINT8 ssid[WF_MAX_SSID_LENGTH];
Description SSID, which must be less than or equal to 32 characters. Set to all 0s if not being used. If ssidLength is 0 this field is ignored. If SSID is not defined then the MRF24WB0M, when using this profile to connect ( see page 168), will scan all channels within its regional domain. Default: SSID not used. Basic Service Set Identifier, always 6 bytes. This is the 48-bit MAC of the SSID. It is an optional field that can be used to specify a specific SSID if more than one AP exists with the same SSID. This field can also be used in lieu of the SSID. Set each byte to 0xFF if BSSID is not going to be used. Default: BSSID not used (all FFs) Number of ASCII bytes in ssid. Set to 0 is SSID is not going to be used. Default: 0 Designates the desired security level for the connection. Choices are:
UINT8 bssid[WF_BSSID_LENGTH];
UINT8 ssidLength;
UINT8 securityType;
UINT8 Set to NULL if securityType is WF_SECURITY_OPEN. If securityKey[WF_MAX_SECURITY_KEY_LENGTH]; securityKeyLength is 0 this field is ignored. UINT8 securityKeyLength; UINT8 wepDefaultKeyId; Number of bytes used in the securityKey. Set to 0 if securityType is WF_SECURITY_OPEN. This field is only used if securityType is WF_SECURITY_WEP. This field designates which of the four WEP keys defined in securityKey to use when connecting to a WiFi network. The range is 0 thru 3, with the default being 0. WF_INFRASTRUCTURE or WF_ADHOC Default: WF_INFRASTRUCTURE Only applicable if networkType is WF_ADHOC. Configures Adhoc behavior. Choices are:
556
11.2 Wi-Fi Connection Algorithm any endian issues prior to calling this function. Remarks None. Preconditions MACInit must be called first. Parameters Parameters CpId elementId p_elementData elementDataLength
Description Connection Profile ID Element that is being set Pointer to element data Number of bytes pointed to by p_elementData
WF_CAGetConnectionProfileList ( see page 561) WF_CAGetDeauthAction ( page 562) WF_CAGetElements ( 562) see
see page
WF_CAGetEventNotificationAction Reads the Connection Algorithm event notification action. ( see page 563) WF_CAGetListenInterval ( page 563) WF_CAGetListRetryCount ( page 564) see see Gets the listen ( see page 172) interval.
Gets the list retry count Gets the Max Channel Time (in milliseconds)
558
11.2 Wi-Fi Connection Algorithm WF_CAGetMinChannelTime ( see page 565) WF_CAGetProbeDelay ( page 565) WF_CAGetRssi ( WF_CAGetScanCount ( page 566) WF_CAGetScanType ( 567) see
Gets the current Connection Algorithm minimum channel time. Gets the Probe Delay (in microseconds) Gets the RSSI threshold Gets the scan count
see page Gets the Connection Algorithm scan type see Sets the beacon timeout value. Action to take if a connection is lost due to a beacon timeout. Sets the channel list. Not currently supported Sets the DeauthAction used by the Connection Algorithm. Writes all Connection Algorithm elements.
WF_CASetConnectionProfileList ( see page 569) WF_CASetDeauthAction ( page 570) WF_CASetElements ( 570) see
see page
WF_CASetEventNotificationAction Sets the WiFi events that the host wishes to be notified of. ( see page 571) WF_CASetListenInterval ( page 571) WF_CASetListRetryCount ( page 572) see see Sets the listen ( see page 172) interval.
Sets the list retry count Sets the maximum channel time (in milliseconds) Sets the minimum channel time (in milliseconds) Sets the Probe Delay (in microseconds) Sets the RSSI threshold Sets the scan count
WF_CASetMaxChannelTime ( see page 573) WF_CASetMinChannelTime ( see page 573) WF_CASetProbeDelay ( page 574) WF_CASetRssi ( WF_CASetScanCount ( page 575) WF_CASetScanType ( 575) Module Wi-Fi Connection Algorithm ( Structures Name WFCAElementsStruct ( page 576) Description see page 558) see
The following functions and variables are available to the stack application.
11.2 Wi-Fi Connection Algorithm C void WF_CAGetBeaconTimeout( UINT8 * p_beaconTimeout ); Returns None. Description
Value Description 0 No monitoring of the beacon timeout condition. The host will not be notified of this event.
1-255 Number of beacons missed before disconnect event occurs and beaconTimeoutAction occurs. If enabled, host will receive an event message indicating connection temporarily or permanently lost, and if retrying, a connection successful event. Remarks None. Preconditions MACInit must be called first. Parameters Parameters p_beaconTimeout Description Pointer where beacon timeout value is written
560
WF_ATTEMPT_TO_RECONNECT WF_DO_NOT_ATTEMPT_TO_RECONNECT
561
562
Description Pointer to the output structure (tWFCAElements) where the connection algorithm elements are written.
Remarks None. Preconditions MACInit must be called first. Parameters Parameters p_eventNotificationAction Description Pointer to where returned value is written.
Gets the Listen Interval used by the Connection Algorithm. This value is measured in 100ms intervals, the default beacon period of APs.
Value Description 1 2 ... MRF24WB0M wakes up every 100ms to receive buffered messages. MRF24WB0M wakes up every 200ms to receive buffered messages. ...
65535 MRF24WB0M wakes up every 6535.5 seconds (~109 minutes) to receive buffered messages. Remarks None. Preconditions MACInit must be called first. Only used when PS Poll mode is enabled. Parameters Parameters p_listenInterval Description Pointer to where listen ( see page 172) interval is returned
564
11.2 Wi-Fi Connection Algorithm C void WF_CAGetMaxChannelTime( UINT16 * p_minChannelTime ); Returns None Description
Gets the maximum time the connection manager waits for a probe response after sending a probe request. Remarks Default is 400ms Preconditions MACInit must be called first. Parameters Parameters p_maxChannelTime Description Pointer where maximum channel time is written
The number of microseconds to delay before transmitting a probe request following the channel change event. Remarks Default is 20uS Preconditions MACInit must be called first. Parameters Parameters p_probeDelay Description Pointer to where probe delay is written
566
The number of times the Connection Manager will scan a channel while attempting to find a particular WiFi network. Remarks Default is 1 Preconditions MACInit must be called first. Parameters Parameters p_scanCount Description Pointer to where scan count is written
Value Description 0 No monitoring of the beacon timeout condition. The host will not be notified of this event.
1-255 Number of beacons missed before disconnect event occurs and beaconTimeoutAction occurs. If enabled, host will receive an event message indicating connection temporarily or permanently lost, and if retrying, a connection successful event. Remarks None. Preconditions MACInit must be called first. Parameters Parameters beaconTimeout Description Number of beacons that can be missed before the action in beaconTimeoutAction is taken.
568
569
570
Description Pointer to the input structure (tWFCAElements) containing the connection algorithm elements.
Remarks None. Preconditions MACInit must be called first. Parameters Parameters eventNotificationAction Description Bit mask indicating which events the host wants to be notifed of.
571
Sets the listen ( see page 172) interval used by the Connection Algorithm. This value is measured in 100ms intervals, the default beacon period of APs.
Value Description 1 2 ... MRF24WB0M wakes up every 100ms to receive buffered messages. MRF24WB0M wakes up every 200ms to receive buffered messages. ...
65535 MRF24WB0M wakes up every 6535.5 seconds (~109 minutes) to receive buffered messages. Remarks None. Preconditions MACInit must be called first. Only used when PS Poll mode is enabled. Parameters Parameters listenInterval Description Number of 100ms intervals between instances when the MRF24WB0M wakes up to receive buffered messages from the network.
572
574
575
UINT8 scanType;
UINT8 rssi;
There are several connection-related events that can occur. The Host has the option to be notified (or not) when some of these events occur. This field controls event notification for connection-related events. Specifies the action the Connection Manager should take if a Connection is lost due to a Beacon Timeout. If this field is set to WF_ATTEMPT_TO_RECONNECT then the number of attempts is limited to the value in listRetryCount. Choices are: WF_ATTEMPT_TO_RECONNECT or WF_DO_NOT_ATTEMPT_TO_RECONNECT Default: WF_ATTEMPT_TO_RECONNECT Designates what action the Connection Manager should take if it receives a Deauthentication message from the AP. If this field is set to WF_ATTEMPT_TO_RECONNECT then the number of attempts is limited to the value in listRetryCount. Choices are: WF_ATTEMPT_TO_RECONNECT or WF_DO_NOT_ATTEMPT_TO_RECONNECT Default: WF_ATTEMPT_TO_RECONNECT List of one or more channels that the MRF24WB0M should utilize when connecting or scanning. If numChannelsInList is set to 0 then this parameter should be set to NULL. Default: All valid channels for the regional domain of the MRF24WB0M (set at manufacturing). Number of channels in channelList. If set to 0 then the MRF24WB0M will populate the list with all valid channels for the regional domain. Default: The number of valid channels for the regional domain of the MRF24WB0M (set at manufacturing). Specifies the number of beacons that can be missed before the action described in beaconTimeoutAction is taken. The number of times to scan a channel while attempting to find a particular access point. Default: 1 The minimum time (in milliseconds) the connection manager will wait for a probe response after sending a probe request. If no probe responses are received in minChannelTime then the connection manager will go on to the next channel, if any are left to scan, or quit. Default: 200ms If a probe response is received within minChannelTime then the connection manager will continue to collect any additional probe responses up to maxChannelTime before going to the next channel in the channelList. Units are in milliseconds. Default: 400ms The number of microseconds to delay before transmitting a probe request following the channel change event. Default: 20us
UINT8 beaconTimeoutAction;
UINT8 deauthAction;
UINT8 channelList[WF_CHANNEL_LIST_LENGTH];
UINT8 numChannelsInList;
UINT16 minChannelTime;
UINT16 maxChannelTime;
UINT16 probeDelay;
577
11.2 Wi-Fi Connection Algorithm LowLevel_CASetElement ( see page 578) SetEventNotificationMask ( see page 579) Module Wi-Fi Connection Algorithm ( Description see page 558)
Set an element of the connection algorithm on the MRF24WB0M. Sets the event notification mask.
The following functions and variables are designated as internal to the module.
11.2 Wi-Fi Connection Algorithm UINT8 elementDataLength ); Returns None. Description LOCAL FUNCTION PROTOTYPES
Low-level function to send the appropriate management message to the MRF24WB0M to set the Connection Algorithm element. Remarks All Connection Algorithm 'Set Element' functions call this function to construct the management message. The caller must fix up any endian issues prior to calling this function. Preconditions MACInit must be called first. Parameters Parameters elementId p_elementData elementDataLength Description Element that is being set Pointer to element data Number of bytes pointed to by p_elementData
Value 0x01 0x02 0x04 0x08 0x10 0x1f Remarks None. Preconditions
Description Bit mask defining which events the host will be notified of.
WF_CMGetConnectionState ( see page 581) WF_CMInfoGetFSMStats ( see page 582) Module Wi-Fi Connection Manager ( Description
The following functions and variables are available to the stack application.
Connection Manager Public Members see page 599) for events that
until the connection attempt is successful, but returns immediately. See WF_ProcessEvent ( can occur as a result of a connection attempt being successful or not.
Note that if the Connection Profile being used has WPA or WPA2 security enabled and is using a passphrase, the connection manager will first calculate the PSK key, and then start the connection process. The key calculation can take up to 30 seconds. Remarks None. Preconditions MACInit must be called first. Parameters Parameters CpId Description If this value is equal to an existing Connection Profiles ID than only that Connection Profile will be used to attempt a connection to a WiFi network. If this value is set to WF_CM_CONNECT_USING_LIST then the connectionProfileList will be used to connect ( see page 168), starting with the first Connection Profile in the list.
581
11.4 Wi-Fi Scan Remarks None. Preconditions MACInit must be called first. Parameters Parameters p_state p_currentCpId
Description Pointer to location where connection state will be written Pointer to location of current connection profile ID that is being queried.
582
The following functions and variables are available to the stack application.
584
WF_TxPowerGetFactoryMax Retrieves the factory-set max Tx power from the MRF24WB0M. ( see page 586) Module Wi-Fi Tx Power Control ( Description The following functions and variables are available to the stack application. see page 584)
minimum and maximum Tx power levels. However, this function can never set a maximum Tx power greater than the factory-set value, which can be read via WF_TxPowerGetFactoryMax ( see page 586)(). Remarks No conversion of units needed, input to MRF24WB0M is in dB. Preconditions MACInit must be called first. Parameters Parameters minTxPower maxTxPower Description Desired minTxPower (-10 to 10dB) Desired maxTxPower (-10 to 10dB)
586
Hibernate
This mode effectively turns the MRF24WB0M off for maximum power savings. MRF24WB0M state is not retained, and when the MRF24WB0M is taken out of the Hibernate state it performs a reboot. Hibernate mode is controlled by toggling the XCEN33 pin on the MRF24WB0M module (high to enter hibernate, low to exit). This mode should be used when the application allows for the MRF24WB0M module to be off for extended periods of time.
Power Save Functions 802.11 chipsets have two well known operational power modes. Active power mode is defined as the radio always on either transmitting or receiving, meaning that when it isn't transmitting then it is trying to receive. Power save mode is defined as operating with the radio turned off when there is nothing to transmit and only turning the radio receiver on when required. The power save mode is a mode that requires interaction with an Access Point. The access point is notified via a packet from the Station that it is entering into power save mode. As a result the access point is required to buffer any packets that are destined for the Station until the Station announces that it is ready to once again receive packets. The duration that a Station is allowed to remain in this mode is limited and is typically 10 times the beacon interval of the Access point. If the host is expecting packets from the network it should operate in Active mode. If however power saving is critical and packets are not expected then the host should consider operating in power save mode. Due to the nature of Access points not all behaving the same, there is the possibility that an Access point will invalidate a Stations connection if it has not heard from the Station over a given time period. For this reason power save mode should be used with caution. The 802.11 name for power saving mode is PS-Poll (Power-Save Poll).
see see
Value Definition ---- --------WF_PS_HIBERNATE MRF24WB0M in hibernate state WF_PS_PS_POLL_DTIM_ENABLED MRF24WB0M in PS-Poll mode with DTIM enabled WF_PS_PS_POLL_DTIM_DISABLED MRF24WB0M in PS-Poll mode with DTIM disabled WF_PS_POLL_OFF MRF24WB0M is not in any power-save state Remarks None. Preconditions MACInit must be called first. Parameters Parameters p_powerSaveState Description Pointer to where power state is written
588
589
Description TRUE if MRF24WB0M should wake up periodically and check for buffered broadcast messages, else FALSE
590
11.7 Wi-Fi Miscellaneous C static void SetPowerSaveState( UINT8 powerSaveState ); Returns None. Remarks None. Preconditions MACInit must be called first. Parameters Parameters powerSaveState
see
WF_GetMultiCastFilter ( see page 593) WF_GetRegionalDomain ( see page 594) WF_GetRtsThreshold ( page 595) WF_SetMacAddress ( page 595) WF_SetMultiCastFilter ( see page 596) WF_SetRegionalDomain ( see page 596) WF_SetRtsThreshold ( page 597) see
see Gets the RTS Threshold see Uses a different MAC address for the MRF24WB0M Sets a multicast address filter using one of the two multicast filters. Enables or disables the MRF24WB0M Regional Domain. Sets the RTS Threshold.
591
11.7 Wi-Fi Miscellaneous Module Wi-Fi Miscellaneous ( Structures Name tWFDeviceInfoStruct ( page 597) WFMacStatsStruct ( page 598) Description see see see page 591)
The following functions and variables are available to the stack application.
592
11.7 Wi-Fi Miscellaneous Preconditions MACInit must be called first. Parameters Parameters p_mac
Description Pointer where mac will be written (must point to a 6-byte buffer)
Address ( see page 144) 0 type [14-19] -- Compare Address ( see page 144) 1 address [20] -- Compare Address ( see page 144) 1 group [21] -- Compare Address ( see page 144) 1 type [22-27] -- Compare Address ( see page 144) 2 address [28] -- Compare Address ( see page 144) 2 group [29] -- Compare Address ( see page 144) 2 type [30-35] -Compare Address ( see page 144) 3 address [36] -- Compare Address ( see page 144) 3 group [37] -- Compare Address ( see page 144) 3 type [38-43] -- Compare Address ( see page 144) 4 address [44] -- Compare Address ( see page 144) 4 group [45] -- Compare Address ( see page 144) 4 type [46-51] -- Compare Address ( see page 144) 5 address [52] -- Compare Address ( see page 144) 5 group [53] -- Compare Address ( see page 144) 5 type Remarks None. Preconditions MACInit must be called first. Parameters Parameters multicastFilterId multicastAddress Description WF_MULTICAST_FILTER_1 or WF_MULTICAST_FILTER_2 6-byte address
594
Directs the MRF24WB0M to use the input MAC address instead of its factory-default MAC address. This function does not overwrite the factory default, which is in FLASH memory it simply tells the MRF24WB0M to use a different MAC. Remarks None. Preconditions MACInit must be called first. Cannot be called when the MRF24WB0M is in a connected state. Parameters Parameters p_mac Description Pointer to 6-byte MAC that will be sent to MRF24WB0M
595
11.7 Wi-Fi Miscellaneous WF_DOMAIN_FCC WF_DOMAIN_IC WF_DOMAIN_ETSI WF_DOMAIN_SPAIN WF_DOMAIN_FRANCE WF_DOMAIN_JAPAN_A WF_DOMAIN_JAPAN_B Remarks None. Preconditions
MACInit must be called first. This function must not be called while in a connected state. Parameters Parameters regionalDomain Description Value to set the regional domain to
597
11.7 Wi-Fi Miscellaneous C struct tWFDeviceInfoStruct { UINT8 deviceType; UINT8 romVersion; UINT8 patchVersion; }; Members Members UINT8 deviceType; UINT8 romVersion; UINT8 patchVersion; Description used in WF_GetDeviceInfo ( see page 592)
UINT32 MibTxBytesCtr; UINT32 MibTxMulticastCtr; UINT32 MibTxFailedCtr; UINT32 MibTxRtryCtr; UINT32 MibTxMultRtryCtr; UINT32 MibTxSuccessCtr; UINT32 MibRxDupCtr;
11.8 WF_ProcessEvent UINT32 MibRxCtsSuccCtr; UINT32 MibRxCtsFailCtr; UINT32 MibRxAckFailCtr; UINT32 MibRxBytesCtr; UINT32 MibRxFragCtr; UINT32 MibRxMultCtr; UINT32 MibRxFCSErrCtr; UINT32 MibRxWEPUndecryptCtr;
Microchip TCP/IP Stack Help Number of CTS frames received in response to an RTS frame. Number of times an RTS frame was not received in response to a CTS frame. Number of times an Ack was not received in response to a Tx frame. Total number of Rx bytes received. Number of successful received frames (management or data) Number of frames received with the multicast bit set in the destination MAC address. Number of frames received with an invalid Frame Checksum (FCS). Number of frames received where the Protected Frame subfield of the Frame Control Field is set to one and the WEPOn value for the key mapped to the transmitters MAC address indicates the frame should not have been encrypted. Number of times that fragments aged out, or were not received in the allowable time. Number of MIC failures that have occurred.
11.8 WF_ProcessEvent
Module Wi-Fi API ( Description There are several events that can occur on the MRF24WB0M that the host CPU may want to know about. All MRF24WB0M events go through the WF_ProcessEvent() function described in the next section. Event Processing The WF_ProcessEvent() function is how the host application is notified of events. This function will be called by the Wi-Fi host driver when an event occurs. This function should not be called directly by the host application. This function, located in WF_Customize.c, should be modified by the user as needed. Since this function is called from the WiFi driver there are some restrictions namely, one cannot call any Wi-Fi driver functions when inside WFProcessEvent. It is recommended that that customer simply set a flag for a specific event and handle it in the main loop. The framework for this function is shown below. The prototype for this function is: UINT16 WF_ProcessEvent(UINT8 event, UINT16 eventinfo); There are two inputs to the function: event eventInfo The event that occurred. Additional information about the event. This is not applicable to all events. see page 541)
The table below shows possible values that the event and eventInfo parameters can have. Note that event notification of some events can be optionally disabled via: 1. Bit mask eventNotificationAction in the tWFCAElements structure (see Wi-Fi Connection Algorithm ( 2. Function WF_CASetEventNotificationAction() ( see page 571). see page 558)), or
599
11.8 WF_ProcessEvent
event WF_EVENT_CONNECTION_SUCCESSFUL
eventInfo The connection attempt was successful. eventInfo: Always WF_NO_ADDITIONAL_INFO (Optional event)
WF_EVENT_CONNECTION_FAILED
The connection attempt failed eventInfo: WF_JOIN_FAILURE WF_AUTHENTICATION_FAILURE WF_ASSOCIATION_FAILURE WF_WEP_HANDSHAKE_FAILURE WF_PSK_CALCULATION_FAILURE WF_PSK_HANDSHAKE_FAILURE WF_ADHOC_JOIN_FAILURE WF_SECURITY_MISMATCH_FAILURE WF_NO_SUITABLE_AP_FOUND_FAILURE WF_RETRY_FOREVER_NOT_SUPPORTED_FAILURE (Optional event)
WF_EVENT_CONNECTION_TEMPORARILY_LOST An established connection was temporarily lost the connection algorithm is attempting to reconnect. The eventInfo field indicates why the connection was lost. eventInfo: WF_BEACON_TIMEOUT WF_DEAUTH_RECEIVED WF_DISASSOCIATE_RECEIVED (Optional event) WF_EVENT_CONNECTION_PERMANENTLY_LOST An established connection was permanently lost the connection algorithm either ran out of retries or was configured not to retry. The eventInfo field indicates why the connection was lost. eventInfo: WF_BEACON_TIMEOUT WF_DEAUTH_RECEIVED WF_DISASSOCIATE_RECEIVED This event can also be generated when WF_CMDisconnect ( see page 581)() is called, in which case the eventInfo field has no meaning.
(Optional event) WF_EVENT_CONNECTION_REESTABLISHED A connection that was temporarily lost has been restablished Always WF_NO_ADDITIONAL_INFO (Optional event) The scan request initiated by calling WF_Scan ( see page 583)() has completed and results can be read from the MRF24WB0M. eventInfo: Number of scan results
WF_EVENT_SCAN_RESULTS_READY
600
12.2 WF_ProcessEvent() Framework Below is the framework for WF_ProcessEvent(). Each case statement should be modified as needed to handle events the application is interested in. void WF_ProcessEvent(UINT8 event, UINT16 eventInfo) { switch (event) { case WF_EVENT_CONNECTION_SUCCESSFUL: /* Application code here */ break; case WF_EVENT_CONNECTION_FAILED: /* Application code here */ break; case WF_EVENT_CONNECTION_TEMPORARILY_LOST: /* Application code here */ break; case WF_EVENT_CONNECTION_PERMANENTLY_LOST: /* Application code here */ break; case WF_EVENT_FLASH_UPDATE_SUCCESSFUL: /* Application code here */ break; case WF_EVENT_FLASH_UPDATE_FAILED: /* Application code here */ break; case WF_EVENT_KEY_CALCULATION_COMPLETE: /* Application code here */ break; case WF_EVENT_SCAN_RESULTS_READY: /* Application code here */ break; case WF_EVENT_IE_RESULTS_READY: /* Application code here */ break; default: WF_ASSERT(FALSE); break; } }
of the Microchip Wi-Fi modules operating with the latest release of the Microchip TCPIP stack.
Wi-Fi Alliance Testing To carry the Wi-Fi Alliance logo, Wi-Fi products must successfully pass numerous tests, including compatibility testing. Wi-Fi compatibility testing is performed against 4 representative access points, with a subset of tests run against each of the access points. Devices are tested against these access points for characteristics such as connectivity, security, throughput, and a breadth of other specifications. Microchip Wi-Fi modules have successfully passed the Wi-Fi Alliance testing. The report is titled WFA7150 and is available at http://certifications.wi-fi.org/pdf_certificate.php?cid=WFA7150
Additional Wi-Fi Compatibility Testing Wi-Fi technology is dramatically expanding the reach and applications of the internet to embedded devices. In many cases, Wi-Fi is new to the markets and applications it is reaching. As a result, Microchip feels it is important to raise the bar on compatibility testing, and education of the developer. Microchip has thus adopted the Wi-Fi.org test bench for more generic Access Point testing. The goal of these tests is to ensure basic connectivity in multiple non-secure and secure scenarios with a global representation of top selling access points.
Pass Criteria The following tests are part of the current testing suite and must pass for the Access Point to be considered compatible. Following in conditions of no security, WEP40 and WEP104, WPA-PSK (TKIP), WPA2-PSK (AES) AP association, Iperf UDP upload/download, Iperf TCP upload/download, DHCP, ICMP ping In many cases there are other modes that can be run with the Access Points and the user must take caution that if the mode is not listed, then compatibility is not necessarily guaranteed. These modes are usually Greenfield use, modes being deprecated by Wi-Fi.org, or cases of limiting the use of the Access Point for more private networking purposes and not for true Wi-Fi compatibility. Examples of special modes not necessarily part of the results: WPA-PSK(AES) security: WPA-PSK security is defined as using TKIP. This is a mixed mode. This mode works if the AP just auto-detects and does not mix. WPA2-PSK (TKIP) security: WPA2-PSK security is defined as using 802.11i with AES. This is a mixed mode. This mode works if the AP just auto-detects and does not mix. 802.11g only, 802.11n only, 802.11g/n only: these are private network modes (cutting out mandatory support for 802.11b). These modes may work if basic rates are limited to 1&2mbps per 802.11.
List of compatible Access Points: 2Wire 1701HG 2Wire 2701HG-B 3COM 3CRWER100-75 3COM WL-524 Actiontec GT704-WG AirLink AR690W Belkin N1 Belkin F5D7231-4 602
11.10 WiFi Tips and Tricks Buffalo WHR-G125 Buffalo WHR-HP-G54 Corega CG-WLAPGMN Corega CG-WLBARGO D-Link DIR-655 D-Link WBR-1310 Dynex DX-WGRTR Level1 WBR-3408 Linksys WRT150Nv1.1 Linksys WRT310N Microsoft MN-700 Netgear WGR614v9 Netgear WGT624v3 Netgear WNDR3300 Netgear WPN824v2 Proxim AP-700 SMC Networks SMCWBR14T-G TP-Link TL-WR541G Westell B90-327W15-06 *Note Tests Performed: Basic association with the AP (no security) Association with WEP security Association with WPA/WPA2-PSK security Ping test validation.
4. Channel Selection - For debug purposes, it is typical to use a fixed channel instead of Auto Channel Selection. If a fixed channel has been selected for the MRF24 Station, select the corresponding channel for the AP. 5. Multicast Passthrough - If using multicast features (ZeroConfig for instance) ensure that the Router is configured to enable forwarding of Multicast packets. 6. Beacon Interval - Set the value for the time interval between AP beacons, typical is 100msec. For lower power, this can be set to a smaller value, say 30mS, if the DTIM interval is correspondingly increased. 7. RTS Threshold - Set the value for the frame size above which RTS/CTS will be used, typical is 2347. 8. Fragmentation Threshold - Set the value for the frame size above which packets will be fragmented, typical is 2346. 9. DTIM Interval - Set the value for Delivery Traffic Indication Message Interval, typical is 3 if the Beacon Interval is set for 100mSec. For lower power with the MRF24WB0M, if the Beacon Interval is set to 30mS, then the DTIM should be set to 100 to allow 300mS DTIM Interval. 10. WLAN Partition (or AP Isolation)- Prevents AP clients from communicating to each other, typically disabled. 11. WMM Enable - Allows wireless multimedia traffic, disable unless necessary for other AP services. 12. Short Guard Interval (GI) - Lowers the guard interval between frames, disable unless necessary for other AP services. 13. WiFi Protected Setup (WPS) - Enables WPS device discovery, disable unless necessary for other AP services. 14. Frame Burst - Enables higher wireless packet throughput, disable unless necessary for other AP services. This may be called turbo, or other marketing terms. 15. CTS Protection Mode Improves reliability of 802.11g traffic, disable unless necessary for other AP services. 16. Key Entry Security can be entered with either a numerical key or an ASCII passphrase. Ensure you enter what the AP expects. If just starting, it is best to have another station like a laptop to validate what the AP is expecting.
1. Null String ESSID It is possible to call WF_CMConnect ( see page 580)(cpId) with a cpId of zero. If this happens, the connection manager can use erroneous values for the SSID, Network Mode, Security configuration, etc. which will cause the module to connect ( see page 168) to a wrong AP or not connect ( see page 168) at all. The only valid values that can be used for connection profile references are 1 and 2 (assuming that the WF_CPCreate ( see page 545)(&cpId) succeeded in creating these profile references prior to the attempted connection).
Work around: When creating a connection profile, verify that the profile number returned is always either 1 or 2. If the returned value is 0, delete the profile and recreate it. When connecting with WF_CMConnect ( see page 580)(cpId), ensure that only a valid profile number previously returned from WF_CPCreate ( see page 545)(&cpId) is used.
2. Management scan message conflict Management messages must always return successful or it causes an assert in the host driver. An unsuccessful 604
management message can occur when the connection retry is enabled (MY_DEFAULT_LIST_RETRY_COUNT>0) causing the device to be scanning due to a dropped connection, and then a disconnect, or connect ( see page 168), or scan command is sent.
Work around: If you are controlling connect ( see page 168)/reconnect from the host actively, then disable all firmware retry by using no scan retry and no de-authorization action.
c. To disable De-authentication action WF_CASetBeaconTimeoutAction ( see page 568)(WF DO NOT ATTEMPT TO RECONNECT);
i. If the return state is WF_CSTATE_NOT_CONNECTED (or WF_CSTATE_CONNECTION_PERMANENTLY_LOST), then this means firmware is in IDLE, so host can issue host scan safely ii. If the return state is WF_CSTATE_CONNECTED_INFRASTRUCTURE, then this means firmware is in CONNECTED. In this case a scan command can be issued but a watchdog timer must be used to time for conflict. Also, ensure the management timer is set for at least 0.4seconds per channel scanned to prevent queued Tx buffer requests from timing out. iii. If return state is WF_CSTATE_CONNECTION_IN_PROGRESS ( or WF_CSTATE_RECONNECTION_IN_PROGRESS), then this means firmware is in the middle of connection process and a scan must not be initiated.
f. If Disconnect function is desired, a watchdog timer needs to be used to address the case where a conflict occurs with an over the air disassociate or deauthorize.
g. For watchdog timing, advised timing is 2x the management packet timeout (that is, use 4seconds unless the management timeout has been increased).
b. If you are only using the firmware retry and not doing ANY connection management (scan, connect ( see page 168), idle, etc.) then you can use MY_DEFAULT_LIST_RETRY_COUNT>0 or retry forever (MY_DEFAULT_LIST_RETRY_COUNT=255). If you lose connection, you can reconnect using the connect ( see page 168) API. Do not use Disconnect. a. If Disconnect function is desired, a watchdog timer needs to be used to address the case where a conflict occurs with an over the air disassociate or deauthorize.
605
12
Microchip TCP/IP Stack Help AnnounceIP function 153 APP_CONFIG Structure 135 appendZeroToOID variable 334
Index _
_checkIpSrvrResponse variable 198 _LoadFATRecord function 285 _MD5_k variable 207 _MD5_r variable 207 _NBNS_HEADER structure 290 _SNMPDuplexInit function 333 _SNMPGet function 333 _SNMPGetTxOffset macro 333 _SNMPPut function 333 _SNMPSetTxOffset macro 334 _TFTP_ACCESS_ERROR enumeration 499 _TFTP_FILE_MODE enumeration 499 _TFTP_RESULT enumeration 500 _tftpError variable 509 _tftpFlags variable 509 _tftpRetries variable 510 _TFTPSendAck function 510 _TFTPSendFileName function 510 _TFTPSendROMFileName function 511 _tftpSocket variable 511 _tftpStartTick variable 511 _tftpState variable 511 _updateIpSrvrResponse variable 198 _Validate function 286
ARP 154 Types 163 ARP Internal Members 160 ARP Public Members 154 ARP Stack Members 159 arp_app_callbacks structure 158 ARP_IP macro 162 ARP_OPERATION_REQ macro 162 ARP_OPERATION_RESP macro 162 ARP_PACKET structure 163 ARP_REQ macro 158 ARP_RESP macro 158 ARPDeRegisterCallbacks function 156 ARPInit function 159 ARPIsResolved function 156 ARPProcess function 159 ARPPut function 161 ARPRegisterCallbacks function 157 ARPResolve function 155 ARPSendPkt function 157 ASN_INT macro 334 ASN_NULL macro 335 ASN_OID macro 335 Authentication 86 Available Demos 83
A
accept function 166 Access Point Compatibility 601 Accessing the Demo Application 75 ACK macro 472 activeUDPSocket variable 536 Additional Features 148 Address 144 Advanced MPFS2 Settings 61 AF_INET macro 167 AGENT_NOTIFY_PORT macro 334 Announce 152 Announce Stack Members 153
B
Base64Decode function 211 Base64Encode function 211 Berkeley (BSD) Sockets 164 BerkeleySocketInit function 178 bForceUpdate variable 197 bind function 167 Bootloader Design 118 BSD Sockets 151 BSD Wrapper Internal Members 179 BSD Wrapper Public Members 165 BSD Wrapper Stack Members 178 BSD_SCK_STATE enumeration 179 a
12 BSDSocket structure 167 BSDSocketArray variable 180 btohexa_high function 212 btohexa_low function 212 Building MPFS2 Images 60
Microchip TCP/IP Stack Help DDNSClient variable 193 DDNSData variable 92 DDNSForceUpdate function 193 DDNSGetLastIP function 194 DDNSGetLastStatus function 194 DDNSInit function 195
C
Cache variable 162 CalcIPBufferChecksum function 213 CalcIPChecksum function 213 CalculateFinishedHash function 396 Clock Frequency 139 closesocket function 168 CloseSocket function 472 COMMUNITY_TYPE enumeration 320 Configure your WiFi Access Point 72 Configuring the Stack 139 Configuring WiFi Security 76 connect function 168 Connecting to the Network 74 Connection Algorithm Internal Members 577 Connection Algorithm Public Members 558 Connection Manager Public Members 580 Connection Profile Internal Members 556 Connection Profile Public Members 544 Cookies 88 Cooperative Multitasking 136 CRPeriod variable 308 curHTTP variable 237 curHTTPID variable 249
ddnsServiceHosts variable 197 ddnsServicePorts variable 197 DDNSSetService function 194 DDNSTask function 195 Demo App 83 Demo App MDD 132 Demo Compatibility Table 79 Demo Information 79 Demo Modules 84 Directory Structure 1 DiscoveryTask function 153 DNS Client 181 DNS Internal Members 185 DNS Public Members 181 DNS_HEADER structure 189 DNS_PORT macro 187 DNS_TIMEOUT macro 187 DNS_TYPE_A macro 184 DNS_TYPE_MX macro 185 DNSBeginUsage function 182 DNSDiscardName function 189 DNSEndUsage function 182 DNSHostName variable 187 DNSHostNameROM variable 187 DNSIsResolved function 184
D
DATA_TYPE enumeration 335 DATA_TYPE_INFO structure 336 DATA_TYPE_TABLE_SIZE macro 336 dataTypeTable variable 336 Daughter Boards 64 DDNS_CHECKIP_SERVER macro 198 DDNS_DEFAULT_PORT macro 199 DDNS_POINTERS structure 191 DDNS_SERVICES enumeration 192 DDNS_STATUS enumeration 192
DNSPutROMString function 186 DNSPutString function 186 DNSResolve function 183 DNSResolveROM function 183 dwInternalTicks variable 518 dwLastUpdateTick variable 373 dwLFSRRandSeed variable 227 dwSNTPSeconds variable 374 dwUpdateAt variable 197 Dynamic DNS Client 190 Dynamic DNS Internal Members 196
12 Dynamic DNS Public Members 190 Dynamic DNS Stack Members 195 Dynamic Variables 85
Microchip TCP/IP Stack Help GET_RESPONSE macro 337 GetDataTypeInfo function 340, 351 gethostname function 169 GetNextLeaf function 351
E
E-mail (SMTP) Demo 93 ENC28J60 Config 140 ENCX24J600 Config 141 Energy Monitoring 133 Explorer 16 and PIC32 Starter Kit 68 External Storage 139 ExtractURLFields function 214
GetOIDStringByAddr function 352 GetOIDStringByID function 352 getSnmpV2GenTrapOid function 359 GetTickCopy function 519 Getting Help 1 Getting Started 64 getZeroInstance variable 368 gGenericTrapNotification variable 322 gOIDCorrespondingSnmpMibID variable 322
F
fatCache variable 286 fatCacheID variable 287 FIN macro 472 FindEmailAddress function 308 FindMatchingSocket function 473, 536 FindOIDsInRequest function 337 FindROMEmailAddress function 309 Flags variable 188 FormatNetBIOSName function 217 Forms using GET 86 Forms using POST 87
Google PowerMeter 132 gSendTrapFlag variable 321 gSendTrapSMstate variable 114 gSetTrapSendFlag variable 321 gSnmpNonMibRecInfo variable 114 gSNMPv3ScopedPduDataPos variable 368 gSNMPv3ScopedPduRequestBuf variable 368 gSNMPv3ScopedPduResponseBuf variable 368 gSnmpv3UserSecurityName variable 114 gSpecificTrapNotification variable 322
H
HandlePossibleTCPDisconnection function 180 HandleTCPSeg function 473 Hardware Configuration 139 Hardware Setup 64 Hash Table Filter Entry Calculator 62 HASH_SUM structure 203 HASH_TYPE enumeration 207 HashAddData function 200 HashAddROMData function 200 Hashes 199 Hashes Internal Members 206 Hashes Public Members 199 Hashes Stack Members 204 hCurrentTCP variable 474 Helpers 209 Functions 225 Variables 227 c
G
gAutoPortNumber variable 180 GenerateHashRounds function 396 GenerateRandomDWORD function 217 GenerateSessionKeys function 397 Generating Server Certificates 377 Generic TCP Client 94 Variables 96 Generic TCP Server 97 Macros 98 GENERIC_TRAP_NOTIFICATION_TYPE enumeration 319 GenericTCPClient function 95 GenericTCPServer function 98 GET_BULK_REQUEST macro 337 GET_NEXT_REQUEST macro 337 GET_REQUEST macro 337
12 Helpers Public Members 210 hexatob function 218 hMPFS variable 338 HOST_TO_PING macro 100 Hot Topics 604 How the Stack Works 134 HSEnd function 397 HSGet function 398 HSGetArray function 398 HSGetWord function 399 HSPut function 399 HSPutArray function 400 HSPutROMArray function 401 HSPutWord function 401 HSStart function 401 HTTP Configuration 112 HTTP_CACHE_LEN macro 250 HTTP_CONN structure 237 HTTP_FILE_TYPE enumeration 250 HTTP_IO_RESULT enumeration 238 HTTP_MAX_DATA_LEN macro 251 HTTP_MAX_HEADER_LEN macro 251 HTTP_MIN_CALLBACK_FREE macro 251 HTTP_PORT macro 251 HTTP_READ_STATUS enumeration 238 HTTP_STATUS enumeration 251 HTTP_STUB structure 252 HTTP_TIMEOUT macro 253 HTTP2 Authentication 233 HTTP2 Compression 235 HTTP2 Cookies 235 HTTP2 Dynamic Variables 228 HTTP2 Features 228 HTTP2 Form Processing 230 HTTP2 Internal Members 248 HTTP2 Public Members 236 HTTP2 Server 227 HTTP2 Stack Members 247 HTTPCheckAuth function 238 httpContentTypes variable 253 HTTPExecuteGet function 239 HTTPExecutePost function 240
Microchip TCP/IP Stack Help httpFileExtensions variable 253 HTTPGetArg function 241 HTTPGetROMArg function 242 HTTPHeaderParseAuthorization function 253 HTTPHeaderParseContentLength function 254 HTTPHeaderParseCookie function 254 HTTPHeaderParseLookup function 255 HTTPIncFile function 255 HTTPInit function 247 HTTPLoadConn function 256 HTTPMPFSUpload function 256 HTTPNeedsAuth function 242 HTTPPostConfig function 90 HTTPPostDDNSConfig function 90 HTTPPostEmail function 91 HTTPPostLCD function 91 HTTPPostMD5 function 92 HTTPPostSNMPCommunity function 89 HTTPPrint_varname function 243 HTTPProcess function 257 HTTPReadPostName function 244 HTTPReadPostPair macro 245 HTTPReadPostValue function 245 HTTPReadTo function 257 HTTPRequestHeaders variable 258 HTTPResponseHeaders variable 258 HTTPS_PORT macro 258 HTTPSendFile function 259 HTTPServer function 248 httpStubs variable 259 HTTPURLDecode function 246 HW_ETHERNET macro 162
I
ICMP 260 ICMP Internal Members 265 ICMP Public Members 261 ICMP_PACKET structure 266 ICMP_TIMEOUT macro 267 ICMPBeginUsage function 261 ICMPEndUsage function 264 ICMPFlags variable 266 d
12 ICMPGetReply function 263 ICMPProcess function 265 ICMPSendPing function 262 ICMPSendPingToHost function 262 ICMPSendPingToHostROM function 263 ICMPSendPingToHostROM macro 264 ICMPState variable 266 ICMPTimer variable 267 ifconfig Commands 126 in_addr structure 170 INADDR_ANY macro 170 INDEX_INFO union 338 Initialization 135 Initialization Structure 150 INOUT_SNMP_PDU enumeration 366 Internet Bootloader 117 Internet Radio 123 Introduction 1 INVALID_SOCKET macro 442 INVALID_TCP_PORT macro 171 INVALID_UDP_PORT macro 522 INVALID_UDP_SOCKET macro 522 IP Address 145 IP_ADDR_ANY macro 171 iperf Example 128 IPPROTO_IP macro 171 IPPROTO_TCP macro 171 IPPROTO_UDP macro 171 IS_AGENT_PDU macro 338 IS_ASN_INT macro 339 IS_ASN_NULL macro 339 IS_GET_NEXT_REQUEST macro 339 IS_GET_REQUEST macro 339 IS_GET_RESPONSE macro 339 IS_OCTET_STRING macro 340 IS_OID macro 340 IS_SET_REQUEST macro 340 IS_SNMPV3_AUTH_STRUCTURE macro 369 IS_STRUCTURE macro 341 IS_TRAP macro 341 IsASNNull function 341 isBufferUsed variable 402
Microchip TCP/IP Stack Help isHashUsed variable 402 isMPFSLocked variable 282 isStubUsed variable 402 IsValidCommunity function 352 IsValidInt function 352 IsValidLength function 348, 353 IsValidOID function 353 IsValidPDU function 353 IsValidStructure function 353 iwconfig Commands 125 iwpriv Commands 127
L
lastBlock variable 207 lastFailure variable 93 lastKnownIP variable 197 LastPutSocket variable 537 lastRead variable 283 lastStatus variable 198 lastSuccess variable 93 leftRotateDWORD function 218 leftRotateDWORD macro 219 LFSRRand function 225 LFSRSeedRand function 226 listen function 172 LoadOffChip function 403 LOCAL_PORT_END_NUMBER macro 474 LOCAL_PORT_START_NUMBER macro 474 LOCAL_UDP_PORT_END_NUMBER macro 537 LOCAL_UDP_PORT_START_NUMBER macro 537 LowLevel_CAGetElement function 578 LowLevel_CASetElement function 578 LowLevel_CPGetElement function 557 LowLevel_CPSetElement function 557
M
MAC Address 144 Main File 135 Main Loop 135 masks variable 403 MAX_FILE_NAME_LEN macro 283 MAX_REG_APPS macro 158 e
12 MAX_TELNET_CONNECTIONS macro 485 MAX_TRY_TO_SEND_TRAP macro 115 MD5AddData function 206 MD5AddROMData function 204 MD5Calculate function 201 MD5HashBlock function 209 MD5Initialize function 202 Memory Allocation 149 Memory Usage 56 MIB Browsers 102 MIB Files 102 MIB_INFO union 341 Microchip TCP/IP Discoverer 62 MPFS_FAT_RECORD structure 286 MPFS_HANDLE type 270 MPFS_INVALID macro 270 MPFS_INVALID_FAT macro 287 MPFS_INVALID_HANDLE macro 270 MPFS_PTR type 283 MPFS_SEEK_MODE enumeration 270 MPFS_STUB structure 283 MPFS_WRITE_PAGE_SIZE macro 284 MPFS2 268 MPFS2 Command Line Options 61 MPFS2 Internal Members 281 MPFS2 Public Members 269 MPFS2 Stack Members 281 MPFS2 Utility 59 MPFS2_FLAG_HASINDEX macro 284 MPFS2_FLAG_ISZIPPED macro 284 MPFSClose function 271 MPFSFormat function 271 MPFSGet function 272 MPFSGetArray function 272 MPFSGetBytesRem function 273 MPFSGetEndAddr function 273 MPFSGetFilename function 274 MPFSGetFlags function 274 MPFSGetID function 275 MPFSGetLong function 275 MPFSGetMicrotime function 276 MPFSGetPosition function 276
Microchip TCP/IP Stack Help MPFSGetSize function 276 MPFSGetStartAddr function 277 MPFSGetTimestamp function 277 MPFSInit function 281 MPFSOpen function 278 MPFSOpenID function 278 MPFSOpenROM function 279 MPFSPutArray function 279 MPFSPutEnd function 280 MPFSSeek function 280 MPFSStubs variable 284 MPFSTell macro 285 msgSecrtyParamLenOffset variable 369 MutExVar variable 507 MySocket variable 309 MyTCB variable 474 MyTCBStub variable 475
N
NBNS 287 NBNS Stack Members 288 NBNS_HEADER structure 290 NBNS_PORT macro 290 NBNSGetName function 288 NBNSPutName function 289 NBNSTask function 289 NextPort variable 484 NOTIFY_COMMUNITY_LEN macro 329 NTP_EPOCH macro 374 NTP_FAST_QUERY_INTERVAL macro 374 NTP_PACKET structure 372 NTP_QUERY_INTERVAL macro 374 NTP_REPLY_TIMEOUT macro 375 NTP_SERVER macro 375 NTP_SERVER_PORT macro 375 numFiles variable 287
O
OCTET_STRING macro 342 OID_INFO structure 342 OID_MAX_LEN macro 328 OIDLookup function 354 f
12
P
PDU_INFO structure 343 Performance Test Internal Members 292 Performance Test Stack Members 290 Performance Tests 290 PERFORMANCE_PORT macro 293 Peripheral Usage 57 PIC18 Explorer 67 PIC18F97J60 Config 143 PIC24FJ256DA210 Dev Board 71 PIC32MX7XX Config 143 PICDEM.net 2 65 Ping (ICMP) Demo 98 Macros 100 PingDemo function 99 Power Save Internal Members 590 Power Save Public Members 587 ProcessGetBulkVar function 359 ProcessGetNextVar function 360 ProcessGetSetHeader function 354 ProcessGetVar function 360 ProcessHeader function 355 ProcessSetVar function 355 ProcessSnmpv3MsgData function 360 ProcessVariables function 355 Programming and First Run 71 Protocol Configuration 146 Protocol Macros and Files 147 PSH macro 475 ptrHS variable 403 PutHeadersState variable 309
recvfrom function 173 reg_apps variable 163 Release Notes 7 RemoteURL variable 96 Replace function 219 REPORT_RESPONSE macro 369 Required Files 134 reqVarErrStatus structure 343 RESERVED_HTTP_MEMORY macro 260 RESERVED_SSL_MEMORY macro 403 ResolvedInfo variable 188 ResponseCode variable 310 ROMStringToIPAddress function 220 ROMStringToIPAddress macro 221 RST macro 475 RTOS 138 RX_PERFORMANCE_PORT macro 293 RXParserState variable 310
S
SaveOffChip function 404 Scan Public Members 582 send function 174 SendNotification function 113 SendPowerModeMsg function 590 SendTCP function 475 SENDTCP_KEEP_ALIVE macro 476 SENDTCP_RESET_TIMERS macro 476 sendto function 174 SERVER_PORT macro 98 ServerName variable 96 ServerPort variable 96
R
ReadMIBRecord function 356 ReadProgramMemory function 285 Reboot 314 Reboot Stack Members 314 REBOOT_PORT macro 315 REBOOT_SAME_SUBNET_ONLY macro 315 RebootTask function 314 RecordType variable 188
SET_REQUEST macro 344 SetErrorStatus function 344 SetEventNotificationMask function 579 SetPowerSaveState function 590 SHA1AddData function 205 SHA1AddROMData function 205 SHA1Calculate function 202 SHA1HashBlock function 208 SHA1Initialize function 202 g
Microchip TCP/IP Stack Help Variables 367 SNMP Internal Members 330 SNMP Operations 106 SNMP Public Members 317 SNMP Server (Agent) 100 Functions 113 Macros 115 Variables 114 SNMP Stack Members 357 SNMP Traps 108 SNMP_ACTION enumeration 319 SNMP_AGENT_PORT macro 344 SNMP_BIB_FILE_NAME macro 345 SNMP_COMMUNITY_MAX_LEN macro 328 SNMP_COUNTER32 macro 345 SNMP_END_OF_VAR macro 328 SNMP_ERR_STATUS enumeration 345 SNMP_GAUGE32 macro 346 SNMP_ID type 327 SNMP_INDEX type 327 SNMP_INDEX_INVALID macro 329 SNMP_IP_ADDR macro 346 SNMP_MAX_MSG_SIZE macro 370 SNMP_MAX_NON_REC_ID_OID macro 115 SNMP_NMS_PORT macro 347 SNMP_NOTIFY_INFO structure 347 SNMP_NSAP_ADDR macro 347 SNMP_OPAQUE macro 348 SNMP_START_OF_VAR macro 328 SNMP_STATUS union 348 SNMP_TIME_TICKS macro 348 SNMP_V1 macro 349 SNMP_V2C macro 349 SNMP_V3 macro 370 SNMP_VAL union 320 SNMPAgentSocket variable 349 SNMPCheckIfPvtMibObjRequested function 356 SNMPGetExactIndex function 360 SNMPGetNextIndex function 327 SNMPGetTimeStamp function 113 SNMPGetVar function 325 SNMPIdRecrdValidation function 361
SM_SSL_RX_SERVER_HELLO enumeration 404 smDNS variable 188 smHTTP macro 260 SMTP Client 294 SMTP Client Examples 294 SMTP Client Internal Members 307 SMTP Client Long Message Example 295 SMTP Client Public Members 297 SMTP Client Short Message Example 294 SMTP Client Stack Members 306 SMTP_CONNECT_ERROR macro 298 SMTP_POINTERS structure 298 SMTP_PORT macro 311 SMTP_RESOLVE_ERROR macro 300 SMTP_SERVER_REPLY_TIMEOUT macro 311 SMTP_SUCCESS macro 300 SMTPBeginUsage function 300 SMTPClient variable 301 SMTPDemo function 94 SMTPEndUsage function 301 SMTPFlags variable 311 SMTPFlush function 301 SMTPIsBusy function 302 SMTPIsPutReady function 302 SMTPPut function 303 SMTPPutArray function 303 SMTPPutDone function 304 SMTPPutROMArray function 304 SMTPPutROMString function 305 SMTPPutString function 305 SMTPSendMail function 306 SMTPServer variable 311 SMTPState variable 312 SMTPTask function 307 smUpload variable 511 SNMP 315 Functions 358 Macros 369 Types 366
12 SNMPInit function 357 SNMPIsNotifyReady function 325 SNMPIsValidSetLen function 362 SNMPNONMIBRECDINFO structure 367 SNMPNotify function 323 SNMPNotifyInfo variable 349 SNMPNotifyPrepare function 326 snmpReqVarErrStatus variable 350 SNMPRxOffset variable 350 SNMPSendTrap function 322 SNMPSetVar function 324 SNMPStatus variable 350 SNMPTask function 357 SNMPTxOffset variable 350
Microchip TCP/IP Stack Help sockaddr_in structure 176 SOCKADDR_IN type 176 socket function 177 SOCKET type 177 Socket Types 149 SOCKET_CNXN_IN_PROGRESS macro 177 SOCKET_DISCONNECTED macro 178 SOCKET_ERROR macro 178 SOCKET_INFO structure 463 Sockets 149 SocketWithRxData variable 537 Software 59 SSL 375 Files 438 SSL Internal Members 391 SSL Public Members 380 SSL Stack Members 384 SSL_ALERT macro 405 SSL_ALERT_LEVEL enumeration 405 SSL_APPLICATION macro 405 SSL_BASE_BUFFER_ADDR macro 406 SSL_BASE_HASH_ADDR macro 406 SSL_BASE_KEYS_ADDR macro 406 SSL_BASE_SESSION_ADDR macro 406 SSL_BASE_STUB_ADDR macro 406 SSL_BUFFER union 407 SSL_BUFFER_SIZE macro 407 SSL_BUFFER_SPACE macro 407 SSL_CERT variable 408 SSL_CERT_LEN variable 408 SSL_CHANGE_CIPHER_SPEC macro 408 SSL_HANDSHAKE macro 408 SSL_HASH_SIZE macro 408 SSL_HASH_SPACE macro 409 SSL_INVALID_ID macro 380 SSL_KEYS structure 409 SSL_KEYS_SIZE macro 410 SSL_KEYS_SPACE macro 410 SSL_MESSAGES enumeration 410 SSL_MIN_SESSION_LIFETIME macro 390 SSL_PKEY_INFO structure 383 SSL_RSA_CLIENT_SIZE macro 384
Snmpv3AESDecryptRxedScopedPdu function 362 Snmpv3BufferPut function 362 Snmpv3FormulateEngineID function 363 Snmpv3GetAuthEngineTime function 363 Snmpv3GetBufferData function 363 Snmpv3InitializeUserDataBase function 363 SNMPV3MSGDATA structure 367 Snmpv3MsgProcessingModelProcessPDU function 364 Snmpv3Notify function 364 Snmpv3ScopedPduProcessing function 364 Snmpv3TrapScopedpdu function 364 Snmpv3UserSecurityModelProcessPDU function 365 Snmpv3UsmAesEncryptDecryptInitVector function 365 Snmpv3UsmOutMsgAuthenticationParam function 365 Snmpv3ValidateEngineId function 365 Snmpv3ValidateSecNameAndSecLvl function 366 Snmpv3ValidateSecurityName function 366 SNMPValidateCommunity function 323 SNTP Client 370 SNTP Client Internal Members 372 SNTP Client Public Members 370 SNTP Client Stack Members 371 SNTPClient function 371 SNTPGetUTCSeconds function 371 SOCK_DGRAM macro 175 SOCK_STREAM macro 175 sockaddr structure 175 SOCKADDR type 176
12
Microchip TCP/IP Stack Help SSLRxClientHello function 424 SSLRxClientKeyExchange function 424 SSLRxFinished function 425 SSLRxHandshake function 425 SSLRxRecord function 426 SSLRxServerCertificate function 426 SSLRxServerHello function 427 sslSession variable 427 sslSessionID variable 428 SSLSessionMatchID function 428 SSLSessionMatchIP function 428 SSLSessionNew function 429 sslSessionStubs variable 429 SSLSessionSync function 430 SSLSessionUpdated macro 430 sslSessionUpdated variable 430 SSLStartPartialRecord function 431 SSLStartSession function 383 sslStub variable 431 SSLStubAlloc function 432 SSLStubFree function 432 sslStubID variable 433 SSLStubSync function 433 SSLTerminate function 433 SSLTxCCSFin function 434 SSLTxClientHello function 434 SSLTxClientKeyExchange function 435 SSLTxMessage function 435 SSLTxRecord function 436 SSLTxServerCertificate function 436 SSLTxServerHello function 437 SSLTxServerHelloDone function 438 Stack API 152 Stack Architecture 134 Stack Performance 56 STACK_USE_SMIV2 macro 115 Standalone Commands 124 StaticVars variable 267 strAuthenticated variable 488 strDisplay variable 488 strGoodBye variable 488 stricmppgm2ram function 221
SSL_RSA_EXPORT_WITH_ARCFOUR_40_MD5 macro 411 SSL_RSA_KEY_SIZE macro 384 SSL_RSA_LIFETIME_EXTENSION macro 390 SSL_RSA_WITH_ARCFOUR_128_MD5 macro 411 SSL_SESSION structure 411 SSL_SESSION_SIZE macro 412 SSL_SESSION_SPACE macro 412 SSL_SESSION_STUB structure 412 SSL_SESSION_TYPE enumeration 413 SSL_STATE enumeration 385 SSL_STUB structure 413 SSL_STUB_SIZE macro 414 SSL_STUB_SPACE macro 414 SSL_SUPPLEMENTARY_DATA_TYPES enumeration 383 SSL_VERSION macro 415 SSL_VERSION_HI macro 415 SSL_VERSION_LO macro 415 SSLBufferAlloc function 415 SSLBufferFree function 416 sslBufferID variable 416 SSLBufferSync function 417 SSLClientSize.h 438 SSLFinishPartialRecord macro 417 SSLFlushPartialRecord macro 417 sslHash variable 418 SSLHashAlloc function 418 SSLHashFree function 418 sslHashID variable 419 SSLHashSync function 419 SSLInit function 386 sslKeys variable 420 sslKeysID variable 420 SSLKeysSync function 420 SSLMACAdd function 421 SSLMACBegin function 421 SSLMACCalc function 421 SSLPeriodic function 386 SSLRSAOperation function 421 sslRSAStubID variable 422 SSLRxAlert function 422 SSLRxAntiqueClientHello function 423 SSLRxCCS function 423
12 StringToIPAddress function 221 strnchr function 222 strPassword variable 489 strSpaces variable 488 strTitle variable 489 STRUCTURE macro 350 strupr function 222 SW License Agreement 3 SwapARPPacket function 161 swapl function 223 swaps function 223 SwapTCPHeader function 476 SYN macro 477 SyncTCB function 477 SyncTCBStub macro 477 SYNQueue variable 477
Microchip TCP/IP Stack Help TCP_OPEN_IP_ADDRESS macro 443 TCP_OPEN_NODE_INFO macro 443 TCP_OPEN_RAM_HOST macro 443 TCP_OPEN_ROM_HOST macro 444 TCP_OPEN_SERVER macro 444 TCP_OPTIMIZE_FOR_SIZE macro 481 TCP_OPTIONS structure 482 TCP_OPTIONS_END_OF_LIST macro 482 TCP_OPTIONS_MAX_SEG_SIZE macro 482 TCP_OPTIONS_NO_OP macro 482 TCP_SOCKET type 466 TCP_SOCKET_COUNT macro 483 TCP_START_TIMEOUT_VAL macro 483 TCP_STATE enumeration 466 TCP_SYN_QUEUE structure 483 TCP_SYN_QUEUE_MAX_ENTRIES macro 484 TCP_SYN_QUEUE_TIMEOUT macro 484
T
TCB structure 464 TCB_STUB structure 465 TCBStubs variable 477 TCP 439 Variables 484 TCP Internal Members 470 TCP Public Members 440 TCP Stack Members 462 TCP/IP Configuration Wizard 59 TCP_ADJUST_GIVE_REST_TO_RX macro 442 TCP_ADJUST_GIVE_REST_TO_TX macro 442 TCP_ADJUST_PRESERVE_RX macro 442 TCP_ADJUST_PRESERVE_TX macro 443 TCP_AUTO_TRANSMIT_TIMEOUT_VAL macro 478 TCP_CLOSE_WAIT_TIMEOUT macro 478 TCP_DELAYED_ACK_TIMEOUT macro 478 TCP_FIN_WAIT_2_TIMEOUT macro 479 TCP_HEADER structure 479 TCP_KEEP_ALIVE_TIMEOUT macro 480 TCP_MAX_RETRIES macro 480 TCP_MAX_SEG_SIZE_RX macro 480 TCP_MAX_SEG_SIZE_TX macro 481 TCP_MAX_SYN_RETRIES macro 481 TCP_MAX_UNACKED_KEEP_ALIVES macro 481
TCP_WINDOW_UPDATE_TIMEOUT_VAL macro 478 TCPAddSSLListener function 381 TCPAdjustFIFOSize function 444 TCPClose function 445 TCPConnect macro 445 TCPDiscard function 446 TCPDisconnect function 446 TCPFind macro 447 TCPFindArray macro 447 TCPFindArrayEx function 447 TCPFindEx function 448 TCPFindROMArray macro 449 TCPFindROMArrayEx function 449 TCPFlush function 450 TCPGet function 450 TCPGetArray function 451 TCPGetRemoteInfo function 451 TCPGetRxFIFOFree function 452 TCPGetRxFIFOFull macro 452 TCPGetTxFIFOFree macro 453 TCPGetTxFIFOFull function 453 TCPInit function 467 TCPIP Demo App Features by Hardware Platform 83 TCPIsConnected function 453 TCPIsGetReady function 454
12 TCPIsPutReady function 454 TCPIsSSL function 382 TCPListen macro 455 TCPOpen function 455 TCPPeek function 457 TCPPeekArray function 457 TCPPerformanceTask function 291 TCPProcess function 468 TCPPut function 458 TCPPutArray function 458 TCPPutROMArray function 459 TCPPutROMString function 459 TCPPutString function 460 TCPRAMCopy function 460 TCPRAMCopyROM function 461 TCPRequestSSLMessage function 386 TCPRXPerformanceTask function 292 TCPSSLDecryptMAC function 469 TCPSSLGetPendingTxSize function 387 TCPSSLHandleIncoming function 387 TCPSSLHandshakeComplete function 388 TCPSSLInPlaceMACEncrypt function 388 TCPSSLIsHandshaking function 381 TCPSSLPutRecordHeader function 389 TCPStartSSLClient function 382 TCPStartSSLClientEx function 469 TCPStartSSLServer function 390 TCPTick function 468 TCPTXPerformanceTask function 293 TCPWasReset function 462 Telnet 485 Telnet Internal Members 487 Telnet Public Members 485 Telnet Stack Members 487 TELNET_PASSWORD macro 486 TELNET_PORT macro 486 TELNET_USERNAME macro 486 TELNETS_PORT macro 486 TelnetTask function 487 TFTP 489 TFTP Internal Members 506 TFTP Public Members 490
Microchip TCP/IP Stack Help TFTP Stack Members 505 TFTP_ACCESS_ERROR enumeration 499 TFTP_ARP_TIMEOUT_VAL macro 505 TFTP_BLOCK_SIZE macro 508 TFTP_BLOCK_SIZE_MSB macro 508 TFTP_CHUNK_DESCRIPTOR structure 502 TFTP_CLIENT_PORT macro 508 TFTP_END_OF_FILE enumeration member 500 TFTP_ERROR enumeration member 500 TFTP_ERROR_ACCESS_VIOLATION enumeration member 499 TFTP_ERROR_DISK_FULL enumeration member 499 TFTP_ERROR_FILE_EXISTS enumeration member 499 TFTP_ERROR_FILE_NOT_FOUND enumeration member 499 TFTP_ERROR_INVALID_OPERATION enumeration member 499 TFTP_ERROR_NO_SUCH_USE enumeration member 499 TFTP_ERROR_NOT_DEFINED enumeration member 499 TFTP_ERROR_UNKNOWN_TID enumeration member 499 TFTP_FILE_MODE enumeration 499 TFTP_FILE_MODE_READ enumeration member 499 TFTP_FILE_MODE_WRITE enumeration member 499 TFTP_GET_TIMEOUT_VAL macro 506 TFTP_MAX_RETRIES macro 506 TFTP_NOT_READY enumeration member 500 TFTP_OK enumeration member 500 TFTP_OPCODE enumeration 508 TFTP_RESULT enumeration 500 TFTP_RETRY enumeration member 500 TFTP_SERVER_PORT macro 509 TFTP_STATE enumeration 509 TFTP_TIMEOUT enumeration member 500 TFTP_UPLOAD_COMPLETE macro 503 TFTP_UPLOAD_CONNECT macro 503 TFTP_UPLOAD_CONNECT_TIMEOUT macro 503 TFTP_UPLOAD_GET_DNS macro 503 TFTP_UPLOAD_HOST_RESOLVE_TIMEOUT macro 504 TFTP_UPLOAD_RESOLVE_HOST macro 504 TFTP_UPLOAD_SEND_DATA macro 504 TFTP_UPLOAD_SEND_FILENAME macro 504 TFTP_UPLOAD_SERVER_ERROR macro 504 TFTP_UPLOAD_WAIT_FOR_CLOSURE macro 505
12 TFTPClose macro 492 TFTPCloseFile function 492 TFTPGet function 493 TFTPGetError macro 493 TFTPGetUploadStatus function 500 TFTPIsFileClosed function 494 TFTPIsFileOpened function 494 TFTPIsFileOpenReady macro 495 TFTPIsGetReady function 495 TFTPIsOpened function 496 TFTPIsPutReady function 496 TFTPOpen function 497 TFTPOpenFile function 498 TFTPOpenROMFile function 498 TFTPPut function 499
U
UART-to-TCP Bridge 116 UDP 520 Types 540 UDP Internal Members 535 UDP Public Members 521 UDP Sockets 151 UDP Stack Members 533 UDP_HEADER structure 538 UDP_OPEN_IP_ADDRESS macro 532 UDP_OPEN_NODE_INFO macro 532 UDP_OPEN_RAM_HOST macro 533 UDP_OPEN_ROM_HOST macro 533 UDP_OPEN_SERVER macro 533 UDP_PORT type 538 UDP_SOCKET type 522 UDP_SOCKET_INFO structure 538 UDP_STATE enumeration 540 UDPClose function 525 UDPDiscard function 525 UDPFlush function 526 UDPGet function 526 UDPGetArray function 527 UDPInit function 534 UDPIsGetReady function 527 UDPIsOpened function 532 UDPIsPutReady function 528 UDPOpen macro 524 UDPOpenEx function 523 UDPPerformanceTask function 291 UDPProcess function 534 UDPPut function 528 UDPPutArray function 529 UDPPutROMArray function 529 UDPPutROMString function 530 UDPPutString function 530 UDPRxCount variable 539 UDPSetRxBuffer function 531 UDPSetTxBuffer function 531 UDPSocketInfo variable 539 UDPTask function 535 m
TFTPUploadFragmentedRAMFileToHost function 501 TFTPUploadRAMFileToHost function 502 Tick Internal Members 518 Tick Module 513 Tick Public Members 514 Tick Stack Functions 517 TICK type 514 TICK_HOUR macro 515 TICK_MINUTE macro 515 TICK_SECOND macro 515 TickConvertToMilliseconds function 515 TickGet function 516 TickGetDiv256 function 516 TickGetDiv64K function 517 TickInit function 517 TICKS_PER_SECOND macro 519 TickUpdate function 518 TransportState variable 313 TRAP macro 351 TRAP_COMMUNITY_MAX_LEN macro 329 TRAP_INFO structure 321 TRAP_TABLE_SIZE macro 329 trapInfo variable 351 tWFDeviceInfoStruct structure 597 Tx Power Control Public Members 584 TX_PERFORMANCE_PORT macro 294
12 UDPTxCount variable 539 uitoa function 224 ultoa function 224 UnencodeURL function 225 UNKNOWN_SOCKET macro 442 uploadChunkDescriptor variable 512
Microchip TCP/IP Stack Help WF_CASetChannelList function 569 WF_CASetConnectionProfileList function 569 WF_CASetDeauthAction function 570 WF_CASetElements function 570 WF_CASetEventNotificationAction function 571 WF_CASetListenInterval function 571 WF_CASetListRetryCount function 572 WF_CASetMaxChannelTime function 573 WF_CASetMinChannelTime function 573 WF_CASetProbeDelay function 574 WF_CASetRssi function 574 WF_CASetScanCount function 575 WF_CASetScanType function 575
uploadChunkDescriptorForRetransmit variable 512 Uploading Pre-built MPFS2 Images 60 Uploading Web Pages 74 URG macro 484 Using the Bootloader 120 Using the Stack 134
V
VENDOR_SPECIFIC_TRAP_NOTIFICATION_TYPE enumeration 319 vTickReading variable 519 vUploadFilename variable 512 vUploadRemoteHost variable 512
WF_CMConnect function 580 WF_CMDisconnect function 581 WF_CMGetConnectionState function 581 WF_CMInfoGetFSMStats function 582 WF_CPCreate function 545 WF_CPDelete function 546 WF_CPGetAdHocBehavior function 546
W
Web Page Demos 84 Functions 89 Variables 92 WebVend 123 WF_CAGetBeaconTimeout function 559 WF_CAGetBeaconTimeoutAction function 560 WF_CAGetChannelList function 561 WF_CAGetConnectionProfileList function 561 WF_CAGetDeauthAction function 562 WF_CAGetElements function 562 WF_CAGetEventNotificationAction function 563 WF_CAGetListenInterval function 563 WF_CAGetListRetryCount function 564 WF_CAGetMaxChannelTime function 564 WF_CAGetMinChannelTime function 565 WF_CAGetProbeDelay function 565 WF_CAGetRssi function 566 WF_CAGetScanCount function 566 WF_CAGetScanType function 567 WF_CASetBeaconTimeout function 567 WF_CASetBeaconTimeoutAction function 568
WF_CPGetBssid function 547 WF_CPGetDefaultWepKeyIndex function 547 WF_CPGetElements function 548 WF_CPGetIds function 548 WF_CPGetNetworkType function 549 WF_CPGetSecurity function 550 WF_CPGetSsid function 551 WF_CPSetAdHocBehavior function 551 WF_CPSetBssid function 552 WF_CPSetDefaultWepKeyIndex function 552 WF_CPSetElements function 553 WF_CPSetNetworkType function 553 WF_CPSetSecurity function 554 WF_CPSetSsid function 555 WF_GetDeviceInfo function 592 WF_GetMacAddress function 592 WF_GetMacStats function 593 WF_GetMultiCastFilter function 593 WF_GetPowerSaveState function 587 WF_GetRegionalDomain function 594 WF_GetRtsThreshold function 595 WF_HibernateEnable function 588
12 WF_ProcessEvent 599 WF_PsPollDisable function 589 WF_PsPollEnable function 589 WF_Scan function 583 WF_ScanGetResult function 584 WF_SetMacAddress function 595 WF_SetMultiCastFilter function 596 WF_SetRegionalDomain function 596 WF_SetRtsThreshold function 597 WF_TxPowerGetFactoryMax function 586 WF_TxPowerGetMinMax function 585 WF_TxPowerSetMinMax function 585 WFCAElementsStruct structure 576 WFCPElementsStruct structure 555 WFMacStatsStruct structure 598 wGetOffset variable 539 wICMPSequenceNumber variable 268 Wi-Fi API 541 Wi-Fi Connection Algorithm 558 Wi-Fi Connection Manager 580 Wi-Fi Connection Profile 544 WiFi Console 124 WiFi EZConfig 130 Wi-Fi Miscellaneous 591 Wi-Fi Miscellaneous Public Members 591 Wi-Fi Power Save 586 Wi-Fi Scan 582 WiFi Tips and Tricks 603 Wi-Fi Tx Power Control 584 wPutOffset variable 540 wUploadChunkOffset variable 513
Z
Zero Configuration (ZeroConf) 116