PSoC™ Creator & Designer Forum Discussions

Where can I find the file cycodeshareexport.ld?

This file is included by the top level linker definition file Generated_Source/PSoC4/cm0gcc.ld (generated by cydsfit.exe).

cycodeshareimport.ld is also included but is also found in the generated source directory.

Where, oh where, has cycodeshareexport.ld gone?

It is not to be found in any of the Cypress installations either. Heavens to Betsy!

Hello,

I followed the instructions in this document [1] and encountered a problem.
It is not possible to link the initial register values to a symbol paramter via `=$param_name` as described there.
Is there is step missing? Is the syntax wrong? Is the UDB Editor buggy on that end?

Thank you in advance

[1] http://www.cypress.com/file/41531/download , p.25

 A simpler version of the EEPROM component.  This component makes using the EEPROM much easier.  Start the EEPROM, then use the byte write or byte read API.

Enjoy!

Hello, 

I'm writing an Bootloader Host (that is, which sends a new Bootloadable to the PSoC bootloader via an UART link), running on another STM32 chip. I can't use the AN68272.zip code due to major architecture differences, so I wrote my own.

I can send most packets without any sort of issue,  in that order : 

- Enter Bootloader (0x38)

- Verify Application Checksum (0x31)

- Flash Array ID (0x32, two times, for both flash chips)

- Send Data (0x37). That's where the problem arises, as I can only send one byte of data at a time. More than one byte of data (size in packet > 1), and the Bootloader answers with a BOOTLOADER_ERR_LENGTH (0x03) error. I'm pretty sure the packet is well formed, that the checksum is valid, and that everything is in place. 

"Flash Array ID" packet also contains more than one byte, and the Bootloader accepts it without issue. 

"Program Row" (0x39) exposes the exact same problem. No matter what I do, it'll answer a 0x03 error.

I've tracked down the error in the Bootloader at the test  if (((pktSize + Bootloader_1_MIN_PKT_SIZE) > numberRead)) in Bootloader_1.c around line 1744.

If someone could point me to the obvious mistake I'm making, I'd be very thankful.  

Thanks a lot !

Here is the full code of my packet generator : 

// Sends a command to the bootloader containing a command ID and optionnal data
uint8_t send_bootloader_packet(uint8_t cmd, uint8_t *data, uint16_t size) {
    uint8_t packet[140]; // FIXME
    uint16_t crc = 0x00;

    packet[0] = 0x01;                                  // Start byte
    packet[1] = cmd;                                   // Command ID
    packet[2] = (uint8_t) (size&0xFF);                 // data length, LSB
    packet[3] = (uint8_t) (size>>8);                   // data length, MSB
    if(size && data) memcpy(&packet[4], data, size);   // Copy data
    crc = bl_basic_summation(packet, size+4);          // Compute CRC on the first 4 bytes and the data
    packet[size+4] = (uint8_t) (crc&0xFF);             // CRC LSB
    packet[size+5] = (uint8_t) (crc>>8);               // CRC MSB
    packet[size+6] = 0x17;                             // End byte

    ​    return send_UART(packet, size+7);
}

EDIT: Packet sent and received : 

Get Flash Size for array 1, works flawlessly

>>> 01 32 01 00 01 CB FF 17                     // Packet 0x32, 1 byte of data, summation checksum
<<< 01 00 04 00 00 00 FF 01 FB FE 17      // Valid answer, usable flash in range 0000-01FF

Send Data,doesn't work

>>> 01 37 08 00 00 40 00 20 91 24 00 00 AB FE 17    // Packet 0x37, 8 bytes of data, summation checksum
<<< 01 03 00 00 FC FF 17                                            // Answer, error 0x03

I love creator.

working on other M3 chips I would rather not switch to their (sometimes expensive) development tools.

has anybody worked with fudging/fooling creator to work with a different chip? i would, in essence be throwing away any results of the CYDWR object but could still use the design schematic to implement software API only (no hardware components). custom API only components could then provide easy to drag on drivers for the hardware specific I/O using the parameteriztion tools for components.

main trick, i believe, is to modify the CyBoot component that is included automagically in every product behind the scenes. it includes the arm required files, the cypress required files, etc.

anyway, i'm going to give it a whack in a clean-room virtual machine with Creator 3.2 to see if i can get it to at least compile and link a simple 'hello world' LED blinker on my Spansion FM3.

this would be a GREAT thing for Cypress/Spansion to consider ....

-Ed

Hello.

Is the source available for the openocd.exe that is shipped with the Windows version of the FX3 SDK? I am encountering some odd connection issues when using GDB and would like to try and fix them.

Many thanks.

Jerry