Wi-Fi Combo Forum Discussions
HI,ALL:
I want to increase bootloader size,and i modify bootapp_link.ld bootloader_link.ld dct_link.ld and dct_only_link.ld as follows:
MEMORY
{
BTLDR_VECTORS (rx) : ORIGIN = 0x08000000, LENGTH = 512
BTLDR_API (rx) : ORIGIN = 0x08000200, LENGTH = 512
BTLDR_CODE (rx) : ORIGIN = 0x08000400, LENGTH = 31K
DCT1_FLASH (rx) : ORIGIN = 0x08008000, LENGTH = 16K
DCT2_FLASH (rx) : ORIGIN = 0x0800C000, LENGTH = 16K
APP_HDR (rx) : ORIGIN = 0x08010000, LENGTH = 512
APP_CODE (rx) : ORIGIN = 0x08010200, LENGTH = 0x6FE00
SRAM (rwx) : ORIGIN = 0x20000000, LENGTH = 96K
}
and modify stm32f4xx_platform.c file about DCT operate:
#define PLATFORM_DCT_COPY1_START_SECTOR ( FLASH_Sector_2 )
#define PLATFORM_DCT_COPY1_START_ADDRESS ( DCT1_START_ADDR )
#define PLATFORM_DCT_COPY1_END_SECTOR ( FLASH_Sector_2 )
#define PLATFORM_DCT_COPY1_END_ADDRESS ( DCT1_START_ADDR + DCT1_SIZE )
#define PLATFORM_DCT_COPY2_START_SECTOR ( FLASH_Sector_3 )
#define PLATFORM_DCT_COPY2_START_ADDRESS ( DCT2_START_ADDR )
#define PLATFORM_DCT_COPY2_END_SECTOR ( FLASH_Sector_3 )
#define PLATFORM_DCT_COPY2_END_ADDRESS ( DCT1_START_ADDR + DCT1_SIZE )
if i modify like this the app can't run,bu moidfy as follows ,the app will work.
MEMORY
{
BTLDR_VECTORS (rx) : ORIGIN = 0x08000000, LENGTH = 512
BTLDR_API (rx) : ORIGIN = 0x08000200, LENGTH = 512
BTLDR_CODE (rx) : ORIGIN = 0x08000400, LENGTH = 15K
DCT1_FLASH (rx) : ORIGIN = 0x08004000, LENGTH = 16K
DCT2_FLASH (rx) : ORIGIN = 0x08008000, LENGTH = 16K
APP_HDR (rx) : ORIGIN = 0x0800C000, LENGTH = 512
APP_CODE (rx) : ORIGIN = 0x0800C200, LENGTH = 0x73E00
SRAM (rwx) : ORIGIN = 0x20000000, LENGTH = 96K
}
STM32F401xD/E Flash module organization table
Show Less
With the newly released SDK 3.1, it appears that the old DCT read/write functions have been deprecated. However, I'm seeing issues with the new functions when writing to the application section. I'm not able to read a previously written value in the application section.
wiced_dct_read_lock( (void**) &p_test, WICED_FALSE, DCT_APP_SECTION, 0, sizeof(some_struct_t)) );
p_test->test = 2;
wiced_dct_write( (const void*) p_test, DCT_APP_SECTION, 0, sizeof(some_struct_t) );
wiced_dct_read_unlock( p_test, WICED_FALSE );
wiced_dct_read_lock( (void**) &p_test, WICED_FALSE, DCT_APP_SECTION, 0, sizeof(some_struct_t) );
WPRINT_APP_INFO(("Rereading test ID after write=%ld\r\n", (long int)p_test->test));
wiced_dct_read_unlock( p_test, WICED_FALSE );
I see "Rereading test ID after write=-1" on the UART.
Can someone from the WICED team please see if there is an issue with the above code and if it should have been working.
Thanks.
Show LessWe can succesfuly setup a connection as client through the wifi direct procedure with an Android Tablet.
But we cannot find the way to have the notification when the tablet choose to disconnect. Can you please advice?
Thanks for the support.
Show LessHi, can WICED audio platfomr support airplay. does airplay need a license to support it .
Intermittently, all of our applications experience premature failure of TCP connections. We noticed that the likelihood of failure grows with bidirectional data transfer and amount of data transfer. After capturing many traces of this phenomena, we have reduced it to a sequence involving a data packet loss in one direction followed by a data packet in the reverse direction.
See the attached trace file for Frame references.
The situation around this problem always takes the following form:
1) A data packet from NetX to Windows TCP is lost. [Between Frame 4894 and Frame 4895, packet Seq 279060 is lost.]
2) Meanwhile Windows sends a data packet to NetX. [Frame 4898 and then Frame 4900.]
3) NetX ACKs the Windows packet while sending more data, not yet aware of the loss. [Frame 4901.]
4) NetX later retransmits the lost data packet. [Frame 4903.] This packet has a fresh IP Identification number but a stale Acknowledgement number (the Acknowledgement number is the same as when the original data packet was transmitted, which is now larger because at least one Microsoft data packet has subsequently been acknowledged).
5) Microsoft ignores the NetX retransmitted data packet.
6) (Optional)If NetX does not see a probe or other packet from Windows, it broadcasts an ARP request. [Frame 4904.] In these cases it goes on to the next step as usual. [Frame 4606.]
7) (Optional) Microsoft sometimes sends a zero window probe. [Frame 4907.] In these cases NetX is properly acknowledging the probe with fresh information. [Frame 4908.]
😎 NetX times out and retransmits data again [Frame 4909.] (always with the stale Acknowledgement number [Ack=278529 verus Ack=280577 in Frame 4907]) until it times out the eighth time. [Frame 4921.]
9) NetX TCP send returns
Show LessWhere do we find the FCC tools for Linux kernel 3.15 with BCM43362?
i defined for my application 2 "custom" GPIOs:
[WICED_GPIO_MYGPIO0] = {GPIOF, 0, RCC_AHB1Periph_GPIOF},
[WICED_GPIO_MYGPIO1] = {GPIOF, 1, RCC_AHB1Periph_GPIOF},
And i wanted to use them as keypad events so i did:
static const gpio_key_t scan_button[] =
{
{ .gpio = WICED_GPIO_MYGPIO0,
.polarity = KEY_POLARITY_HIGH
}
};
and in the main application called
opsuccess=gpio_keypad_enable(&ScanApControl_Keypad, WICED_HARDWARE_IO_WORKER_THREAD,scan_control_keypad_handler, 250, 2, scan_button ); |
if(opsuccess==WICED_SUCCESS) | |
{ | |
WPRINT_APP_INFO( ("IRQ SETUP OK !!\r\n") ); | |
} | |
else | |
{ | |
WPRINT_APP_INFO( ("IRQ SETUP ERROR!!\r\n") ); | |
} |
Than i declared the callback
static void scan_control_keypad_handler(gpio_key_code_t keyCode, gpio_key_event_t event)
{
if (event == KEY_EVENT_PRESSED
{
WPRINT_APP_INFO( ("KEY EVENT TRIGGERED!!\r\n") );
}
}
The problem is that if i do use WICED_GPIO_MYGPIO1 everything works smootly but if i use WICED_GPIO_MYGPIO0 i get "IRQ SETUP OK" but the callback is never triggered.
Does anybody can explain why? Maybe a bug on interrupt masking of PF0 pin?
Thanks for you support
Show Less