I use PSoC 4200 BLE and RTC module with DTS correction and it only works correctly if the module is initialized in the same year.
When next year comes, the correction no longer works.
If I initialize the module at the end of the year, the correction will not work at all.
This is because the calculation of the Unix time value of the correction time occurs at the moment when it is applied, and it would be necessary to increment the value of the year so that the value of the Unix time corresponds to the next year.

</

void RTC_Update(void)
{
static uint32 RTC_currentTickNumber = 0u;
RTC_currentTickNumber += RTC_updateTimePeriod;

if(RTC_currentTickNumber >= RTC_tickRefOneSec)
{
RTC_unixTime++;
RTC_currentTickNumber =
(uint32) RTC_currentTickNumber - RTC_tickRefOneSec;

#if(0u != RTC_INITIAL_DST_STATUS)
if(RTC_unixTime == RTC_unixTimeDstStart)
{
RTC_dstStatus = 1u;
RTC_dstTimeOffset = RTC_SECONDS_PER_HOUR;
}

if(RTC_unixTime == (RTC_unixTimeDstStop - RTC_dstTimeOffset))
{
RTC_dstStatus = 0u;
RTC_dstTimeOffset = 0u;

Here mast be an increase of year value in RTC_dstStartTime struct and RTC_dstStopTime struct
RTC_unixTimeDstStart = RTC_GetDstUnixTime(&RTC_dstStartTime);
RTC_unixTimeDstStop = RTC_GetDstUnixTime(&RTC_dstStopTime);
}
#endif /* (0u != RTC_INITIAL_DST_STATUS) */

#if(0u != RTC_INITIAL_ALARM_STATUS)
if((RTC_unixTime + RTC_dstTimeOffset) == RTC_unixTimeAlarm)
{
RTC_currentTimeDate.status |= (1uL << RTC_STATUS_ALARM_OFFSET);
RTC_alarmCurStatus = RTC_alarmCfgMask;

RTC_unixTimeAlarm =
RTC_GetNexAlarmTime(RTC_unixTime + RTC_dstTimeOffset,
(uint8)RTC_alarmCfgMask);

/* Call callback function only after new alarm time is obtained.
* Cypress ticket #264756
*/
if (RTC_alarmCallbackPtr != NULL)
{
RTC_alarmCallbackPtr();
}
}
#endif/* (0u != RTC_INITIAL_ALARM_STATUS) */
}
}

/>

https://youtu.be/cqfrZvlawEo

I am currently using the PSoC6 and have downloaded the mtb-anycloud-wifi-bluetooth-tester. I am measuring packet rates at have achieved around 15 to 16 kbps. Is there a way that I can increase this to 40 kbps?

Hi all,

I have a CY8CKIT-062-WIFI-BT dev kit and recently have come across a persistent annoying error even during compilation of a sample application such as snip.scan. While making sure other processes and applications weren't running that would use OpenOCD drivers, the console output during a build of snip.scan still complains. Here is a sample of the latest output. Any edits I've attempted to make would only be on the snip.c source file which is only adding print statements.

"**** OpenOCD failed - ensure you have installed the driver from the drivers directory, and that the debugger is not running **** In Linux this may be due to USB access permissions. In a virtual machine it may be due to USB passthrough settings. Check in the task list that another OpenOCD process is not running. Check that you have the correct target and JTAG device plugged in. ****"
Resetting target
Target running
Build complete

Please advise - this hasn't happened before when I worked on this devkit but I feel I might be overlooking something with my build targets ("snip.scan-CY8CKIT_062 download_apps download run" and " snip.scan-CY8CKIT_062 download run ") or setup of the devkit. Very rarely, the build will complete without this error. WICED version is 6.6

I'm working on the example code for the BLE_remote. I'm trying to understand and parse the `.hcd` file that is generated when I build the program.

Looking at configdef20735B1.hdf  I see the following:

     COMMAND "Data" 0x0103
     {
         doc "Config item code used to write an arbitrary chunk of data to an arbitrary address."
         PARAM "Address"
             uint32
             doc "The address to which the Data bytes are to be loaded.";
         PARAM "Data"
             uint8[0xFF00] omit_pad_bytes
             doc "The data bytes to be loaded to the Address specified. The data with arbitrary length. "
                 "The length is implied by the size of the array specified for data, as in data = {0x01, 0x02}.";
     }

I don't understand how the following line is being treated

uint8[0xFF00] omit_pad_bytes

Looking at the output `.hcd` file (which I understand is the outcome of when this file is parsed, along with the .cgs file) I cannot conciliate the data that I pass and it's length to the length bytes in the "packet".

For example, this is a packet of data passed in the BLE_HID_Remote.cgs file:

ENTRY "Data" = "CODE_AREA from tier2/Generic/fcbga/bld/20735_ram_ext.elf"
{
    "Address" = 0x270400
    "Data" =
    COMMENTED_BYTES
    {
        <hex>
        07 b4 00 f0 49 fb 00 28 02 d0 07 bc bd e8 f0 8f
        07 bc 01 23 13 70 df f5 a3 bc 00 00 a8 f8 68 02
        bd e8 f0 81 00 f0 68 fe 10 bd 00 00 00 f0 9e fe
        b0 f5 8c bc bd e8 f0 47 00 f0 5a bf 08 46 33 f6
        e4 ff 03 20 bd e8 f0 81 bd e8 10 40 01 f0 3c b8
        (...)
        00 28 f9 d0 08 30 70 bd 44 d3 20 00 04 05 00 81
        68 d3 20 00 04 06 00 81 10 b5 4e f6 05 f9 01 49
        08 70 10 bd 9a 3e 20 00
    } END_COMMENTED_BYTES

Where there are a total of 32369 bytes (i.e. 0x7e71).

But the BLE_HID_Remote_download.hcd file, on the section that pertains to this "packet", has 0x7ebc as the length of the packet (bytes 0x23f-0x240).

00000230  03 54 01 73 03 54 01 73  03 11 01 01 01 03 01 bc  |.T.s.T.s........|
00000240  7e 00 04 27 00 07 b4 00  f0 4c fc fd f2 41 00 ff  |~..'.....L...A..|
00000250  49 fb 00 28 02 d0 07 bc  bd e8 f0 8f 07 bc 01 23  |I..(...........#|
00000260  13 70 df f5 a3 bc 00 00  a8 f8 68 02 bd e8 f0 81  |.p........h.....|

What explains this difference?

Thank you

Hi,

I'd like to wake up from deep-sleep  when counter's capture interrupt event occurs.  I think this interrupt source cannot wake the device from deep-sleep mode, correct me if I'm wrong.  If this is the case, is there a way (trick) to accomplish this?  

Thanks

I'm working on a BLE project which has one output data service with three characteristics in it (that correspond to the three data channels I need to send). I'm sending all this data using notifications.

For some reason when I use any of the iOS BLE apps (For example in the screenshot below I have the nRF Connect App for iOS) I cannot see all the characteristics. I can see one of them but I still can't enable the notifications even for that one characteristic. (this happens with the Cysmart app, LightBlue iOS apps as well).

The weird thing about this is that when I use the Android counterparts of the same apps, I don't have this problem. I can see all the characteristics and I can even enable the notifications for them.

Is there anything I can do here to fix this issue with the iOS 

This is how my characteristic definitions look like (I can share the code text itself just let me know)

UVC based application for FX3 is created based on the framework of AN75779.  24bit GPIF is used(D23:D0) . image is 800*600.  Pixel depth is 24bit/pixel, i.e. 3Byte/pixel.  Since it is 24bits/pixel raw image, GUID for RGB888 is used for media type and RGB888 will be debayered in host.   DMA buffer keeps the same: 16kB, 4 counts, 2 sockets.  Only change the GPIF bus to 24bits, LD_DATA_COUNT, LD_ADDR_COUNT to 5455. However, it can't stream. 

But according to KBA226722,  

S= 800*600*3= 1,440,000 byte,

F= int(S/(16384-16))= 1440000/16368 = 87

P= fraction of S/(16384-16) * 16368 = 0.976594*16368 = 15984

It should be working. 

I noticed that in KBA226722 , it mentioned in item 5 "If exact line data (i.e nothing is appended at the end of the line data) is intended to be sent to the Host, then make sure that line size in bytes is divisible by GPIF bus width (in bytes)."  I don't quite get this point. 

Help is needed on the proper  setting of DMA configuration and GPIF state machine data and address count value. 

Thanks in advance